From: Giovanni P. Deretta (gpderetta_at_[hidden])
Date: 2006-05-06 09:55:49
Xi Wang wrote:
> On 5/6/06, Giovanni P. Deretta <gpderetta_at_[hidden] > wrote:
>
>> Xi Wang wrote:
>>> It looks great.
>>> I still don't catch why there must be a "self" as the first parameter
>>> in a coroutine definition. Could the "current" function help here?
>>> If removed, the "yield" function would be much easier to use.
>>>
>> The coroutine return type is statically defined. Thus yield (that is
>> both a form of return and call) must know the return type and the
>> argument types. The only way to statically type check these types is to
>> make yield a member of the coroutine or take the coroutine as a
>> parameter. In both cases the coroutine needs a pointer to itself. A
>> current coroutine global pointer would necessarily erase all type
>> informations, and a global yield function that uses this pointer would
>> need to delay all checking until runtime. This would both slow down
>> yielding and prevent the compiler from checking error a compile time.
>> Note that in the "Other Issues" section there is a mention of a free
>> yield function that uses the current_coroutine pointer. But this
>> wouldn't be the prefered interface, if it is implemented at all.
>
>
> I see. A free yield may be not so bad, for most operating systems support
> retrieving current coroutine:-) Besides, what is the return type of "yield"?
> In the document I see
> tie(parm_1, parm_2,... parm_n) = self.*yield*(result_1, result_2,...
> result_n);
> I guess it should just return an integer or something else, not a real
> tuple, right?
>
No, yield returns an actual tuple. The element types of the tuple are
the same types of the function arguments. For example:
tuple<a_t, b_t, c_t> some_function
(corutine<tuple<a_t, b_t, c_t>(d_t, e_t, f_t)>& self,
d_t d,
e_t e,
f_t f) { // 1
a_t a;
b_t b;
c_t c;
while(true) {
do_something_with(d, e, f);
a = some_value;
b = some_other_value;
d = yet_some_other_value;
tie(d, e, f) = self.yield (a, b, d); // 2
}
}
int main() {
coroutine<corutine<tuple<a_t, b_t, c_t>(d_t, e_t, f_t)>
my_coroutine(some_function);
a_t a;
b_t b;
c_t c;
d_t d = ...;
e_t e = ...;
f_t f = ...;
tie(a, b, c) = my_coroutine(d, e, f); // 3
do_something with a, b, c, d, e, f;
tie(a, b, c) = my_coroutine(d, e, f); // 4
}
The first time a coroutine is entered (from 3), execution start at the
main entry point (1). Each tuple can have an arbitrary number of
arguments and results (using tuples), but their type and number is fixed
at compile time. At the yield point control is relinquished to the
caller. The argument values of yield will be returned to the caller as
if the coroutine function had returned. (Note that yield is special
cased for the tuple case and one is not required to write
self.yield(make_tuple(...))). Yield is *not* the same thing as return
because the current scope is not exited, stack is not unwound and thus
scoped objects are not destroyed. This allows us to reenter the scope.
Next time the coroutine is invoked (note that for the caller there is
*no* syntax distinction from first time invocation and successive ones),
control is resumed at the yield point. Yield gives to the coroutine the
values passed as parameter by the caller. As the parameter types and
numbers are the same of the main entry point (i.e. the function
signature), yield must know it (or be checked at run time).
I'm a strong believer of static type checking and I think that
coroutines should be statically checked. Of course I see the usefulness
of postponing checks until runtime. a coroutine<boost::any(boost::any)>
would do it, and the library could have special support for it. But the
preferred interface would be statically checked.
> If the point is to check the return type, maybe we can trick the compiler
> like this:
> int __yield(T);
> #define yield(val) if (__yield(val) < 0) return val;
> If the return value of __yield should not be less than 0, the compiler would
> check
> the type of "val" automatically.
>
Apart for my general dislike for macros (except when you can't really do
without :) ), this wouldn't work because return would exit the scope and
cause all locals to be destroyed.
It is possible to implement a kind of pseudo-coroutines using a
variation of the duff device (see
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html), where the
yield is actually substituted by return, but they are severely limited.
All your locals become static, thus are thread unsafe; it uses unsafe
macros; the syntax is not natural as it requires special macros; and
most importantly you can't have multiple instances of the same coroutine.
>
>>> Another question is, does a "coroutine" object act as both a coroutine
>>> instance and a coroutine factory? According to the examples it seems
>>> that sometimes a coroutine binds data when created, and sometimes
>>> a coroutine uses operator () to create a new instance, right?
>>>
>> Probably I should mark more clearly the pseudocode examples where I make
>> liberal use of the coroutine keyword both to create new instances and to
>> mark a coroutine body) and actual C++ code.
>>
>> In C++, a coroutine object *always* represent a single instance. The
>> constructor binds the coroutine with the function object that implement
>> the body. coroutine::operator(...) resumes (or start, if not already
>> started) the specific coroutine instance to which is applied.
>
>
> What confused me is that coroutine::operator(...) takes parameters.
> Does this mean the parameters of a coroutine can be bound at either
> creation time or invocation time or both? It seems that coroutine::operator
> ()
> mixes the responsibilities of both binding and resuming, which should be
> separated, in my opinion.
>
coroutine::operator() always invokes a coroutine. Binding is done only
at creation time (in the constructor). I thought the article was clear.
If you could point out where the confusion is, I will try to make it
more clear.
Also consider that in pseudocode 'coroutine' is not an object but a
keyword that introduces (possibly lambda) a coroutine body. In the
pseudocode every 'coroutine' body is a diferent instance. Should I make
this more clear?.
-- Giovanni P. Deretta