Re: Lightweight tasks to implement co-routines?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2017-07-31 20:08, Victor Porton wrote:
> This is a question primarily to Dmitry A. Kazakov who (if I don't mistake)
> proposed using lightweight tasks for co-routines.
> 
> I do not quite understand how exactly it should be done:
> 
> A task may contain several accepts with different names, but a co-routine
> can contain only one type of entry and it is always with one variable with
> "out" type (more conveniently represented as a function).

First. A co-routine "task" may have any number of entries, of course.

Second. The actual problem, how I see it, is that this is not an entry. 
If we consider the major use case, a producer-consumer pair, their 
interaction is impossible into an entry-call relation. The comfortable 
design is rather when the producer calls and so yields to the consumer 
when it has items to give away. The consumer calls and so yields to the 
producer when it needs another item to process.

I have a vague idea that it should be an entry of some ad-hoc fake 
protected object that would glue both calls together, or maybe an entry 
of the "carrier" task. But I don't know how to make this easy to use and 
encapsulated without exposing to other contexts.

> So should we standardize that tasks which serve as co-routines should have
> entries with the same name only?

No, see above. If a co-routine enters into a selective or other accept, 
it just yields. A delay alternative could be OK too. The effect would be 
that yielding from some other co-routine, basically when it terminates, 
would land there. Of course, there is no any guarantee about the actual 
waiting time, except that when yielding to the delay alternative, the 
"carrier" task is blocked until the timeout gets expired.

> Isn't it more convenient to make them like "yield" keyword in Python? We can
> for example require that all accepts have the name Yield and one out
> argument. (However, see above about using functions instead.)

Yield without a target is pointless. I see no case where it could be 
useful. When a co-routine yields it is only because it awaits for 
certain data. These data must be parameters of a call or else accept.

Just yielding and letting the run-time to decide who's next is called 
*scheduling*, the thing we have for tasks, and don't want for co-routines.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de