Re: [boost] [SoC][Coroutine] Coroutine design

From: Xi Wang (xi.wang_at_[hidden])
Date: 2006-05-06 04:33:13

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?

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.

> > 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.

Any way, I will modify the pseudocode examples to conform to a single
> interface.
>
> Thanks for the feedback.
>
> --
> Giovanni P. Deretta
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
>