Re: Broadcast / iterate to all Connection objects via Simple Components?

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 2023-02-13 13:57, Dmitry A. Kazakov wrote:
> On 2023-02-13 12:07, Emmanuel Briot wrote:
>> On Monday, February 13, 2023 at 11:55:10 AM UTC+1, Dmitry A. Kazakov 
>> wrote:


    [ snip discussion of network programming details, retain
      discussion about co-routines ]


>>> I'd like to have special Ada "tasks" acting as co-routines on top of
>>> proper tasks yielding when the socket buffer is empty or full.
>>
>> This is an approach we had discussed at AdaCore before I left.  There 
>> are multiple drawbacks
>> here: the limited stack size for tasks by default (2MB), the fact that 
>> entries cannot return indefinite
>> types, the fact that currently those tasks are assigned to OS threads 
>> (so too many of them does
>> impact resource usage),...
> 
> My idea is to have these as pseudo-tasks scheduled by the Ada run-time 
> and not mapped onto any OS threads. A proper thread would pick up such a 
> task and run it until it yields. The crucial point is to use the stack 
> of the pseudo-task in place of the thread's stack or backing it up and 
> cleaning the portion of the stack at the point of yielding, whatever.
> 
>> A colleague had found an external library that would provide several 
>> stacks and thus let people
>> implement actual co-routines.  We did not do much more work on that, 
>> but it was a nice proof
>> of concept, and efficient.  I think things are mostly blocked now, as 
>> the ARG has been discussing
>> these topics for quite a few years now.
> 
> I have an impression that ARG's view on co-routines totally ignores the 
> use case of communication stacks and other cases state machines show 
> their ugly faces...


So your co-routines would (1) have their own stack and (2) be 
independently schedulable, which implies (3) having their own execution 
context (register values, instruction pointer, etc.) How is that 
different from the Ada concept of a "task"? How could the ARG separate 
between a "task" and a "co-routine" in the Ada RM?

There exist Ada compilers and run-times where the tasking concept is 
implemented entirely in the run-time system, without involving the 
underlying OS (if there even is one). That approach was mostly abandoned 
in favour of mapping tasks to OS threads, which makes it easier to use 
potentially blocking OS services from tasks without blocking the entire 
Ada program.

So is your problem only that using OS threads is less "efficient" than 
switching and scheduling threads of control in the run-time system? If 
so, that seems to be a quality-of-implementation issue that could be 
solved in a compiler-specific way, and not an issue with the Ada 
language itself.

The point (from Emmanuel) that task entries cannot return indefinite 
types is certainly a language limitation, but seems to have little to do 
with the possible differences between tasks and co-routines, and could 
be addressed on its own if Ada users so desire.