Lightweight tasks to implement co-routines?

Lightweight tasks to implement co-routines?

[Victor Porton]

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

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

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

If we so much modify the task API for implementing co-routines, isn't it 
lost the sense to use task API for this at all? For me it seems that we 
should instead go Python way and implement it as special functions with some 
kind of "yield" operator. What is the opinion of these who understand?

-- 
Victor Porton - http://portonvictor.org

Re: Lightweight tasks to implement co-routines?

[Simon Wright]

Victor Porton <porton@narod.ru> writes:

> If we so much modify the task API for implementing co-routines, isn't
> it lost the sense to use task API for this at all?

Consider the Ravenscar profile, which doesn't allow tasks to have
entries at all.

Re: Lightweight tasks to implement co-routines?

[Dmitry A. Kazakov]

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

Re: Lightweight tasks to implement co-routines?

[Randy Brukardt]

"Victor Porton" <porton@narod.ru> wrote in message 
news:olnrmv$1quu$1@gioia.aioe.org...
...
> If we so much modify the task API for implementing co-routines, isn't it
> lost the sense to use task API for this at all? For me it seems that we
> should instead go Python way and implement it as special functions with 
> some
> kind of "yield" operator. What is the opinion of these who understand?

Perhaps because defining a new kind of program unit in Ada would take 
hundreds of hours of work rewriting the Standard, and thousands of hours of 
implementor time? Are the problems that can be solved more convienently 
using such a construct common enough to justify that effort (which 
necessarily would replace effort that would be spent solving other kinds of 
problems - such as parallelization)?

From my perspective, generators are exactly the wrong way to write anything, 
since they are inherently sequential. The world is moving rapidly to a more 
parallel environment, and Ada already has far too many constructs that have 
to be handled sequentially. It's hard to justify one more, and especially 
one that seems only of interest to fans of Python.

                                       Randy.
 

Re: Lightweight tasks to implement co-routines?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:olo5rp$dp0$1@gioia.aioe.org...
> On 2017-07-31 20:08, Victor Porton wrote:
...
> 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.

Tucker Taft is proposing a construct called a "channel" for this purpose. It 
sounds interesting, but there are so few details it is impossible to tell. 
There is an AI for it (AI12-0197-4), but it is empty pending a real proposal 
from Tucker.

                         Randy.

Re: Lightweight tasks to implement co-routines?

[Dmitry A. Kazakov]

On 2017-08-01 06:56, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:olo5rp$dp0$1@gioia.aioe.org...
>> On 2017-07-31 20:08, Victor Porton wrote:
> ...
>> 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.
> 
> Tucker Taft is proposing a construct called a "channel" for this purpose. It
> sounds interesting, but there are so few details it is impossible to tell.
> There is an AI for it (AI12-0197-4), but it is empty pending a real proposal
> from Tucker.

Yes, at least the use case is same.

One very important thing though. The construct cannot be statically 
nested as suggested. Consider the case when one producer distributes 
items among several consumers. As a practical example take a multiple 
socket select in the producer that then yields to one of the consumers 
to handle the active socket or else to process socket I/O data.

1. You don't know in advance how many consumers (connections) there will be.

2. There are multiple groups of identical consumers.

I am sure there could be cases with multiple producers as well.

This is why I thought that a task would be a much better way to express 
co-routine than some nested block.

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

Re: Lightweight tasks to implement co-routines?

[Paul Rubin]

Victor Porton <porton@narod.ru> writes:
> Isn't it more convenient to make them like "yield" keyword in Python?

Python's "yield" keyword, originally for "simple generators", has been
improve some since then, but it's still a contorted form of coroutine.

You might look at the Lua coroutine article for a wider discussion
of different styles of coroutine implementation:

http://www.inf.puc-rio.br/~roberto/docs/corosblp.pdf