Re: Feature suggestion: different task schedules

[Victor Porton <porton@narod.ru>]

Dmitry A. Kazakov wrote:

> On 18/07/2017 22:09, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:okkcgc$1m31$1@gioia.aioe.org...
>>> On 18/07/2017 02:09, Randy Brukardt wrote:
>> ...
>>>> And most important of all -- what problem
>>>> needs to be solved.
>>>
>>> A co-routine with task interface lacking task overhead.
>> 
>> I hate to sound like a broken record, but that's a solution, not a
>> problem. One would need to explain what problem(s) can't be reasonably
>> solved with the existing features of Ada that could be solved with a
>> co-routine. (And a purely performance argument is by far the weakest
>> IMHO; very few programs are really performance bound, and most of those
>> would value more tasking.)
> 
> It is not performance argument. It is it the first line design argument
> (control flow inversion) as I explained in another post.
> 
> I admit that I don't understand the OP proposal. It is not sufficiently
> described and scheduling is not single issue here. Not in the cases I
> have in mind.
> 
> A task based solution is non-starter for two reasons.
> 
> One is that it is not composable. I expect a co-routine proposal to
> offer a possibility to implement stacked layered protocols. I don't see
> how that would be possible on task basis. A protocol implementation may
> not be a task object.

I don't understand why it is not composable. A task may call another tasks. 
Tasks may even call each others in a cycle.

However I think, we may have some sort of problem about specifying something 
in hypothetical Ada2020 what is similar to `yield from` in Python. It seems 
that for this we need to introduce something like "multi" accept statement, 
but I did not yet thought about this.

> Another reason is design and OS constraints. Protocols must be handled
> by worker tasks. Number of tasks <<< number of connections, e.g. number
> of sockets.

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