Re: Feature suggestion: different task schedules

["Alejandro R. Mosteo" <alejandro@mosteo.com>]

On 23/07/17 14:31, Victor Porton wrote:
> 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.

I'm not sure if this has been discussed here or if it is even the same 
feature as in Python, but there is an AI proposal for generator 
functions using "yield":

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0197-1.txt?rev=1.7&raw=N

Álex.

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