help / color / mirror / Atom feed
From: "Dmitry A. Kazakov" <>
Subject: Re: Broadcast / iterate to all Connection objects via Simple Components?
Date: Mon, 13 Feb 2023 16:10:15 +0100	[thread overview]
Message-ID: <tsdjsm$261rj$> (raw)
In-Reply-To: <>

On 2023-02-13 14:22, Niklas Holsti wrote:
> On 2023-02-13 13:57, Dmitry A. Kazakov wrote:

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

Sure. You should be able to implement communication logic in a natural way:

1. Read n bytes [block until finished]
2. Do things
3. Write m bytes [block until finished]
4. Repeat

> How is that 
> different from the Ada concept of a "task"?

It is no different, that the whole point of deploying high level 
abstraction: task instead of low level one: state machine.

> How could the ARG separate 
> between a "task" and a "co-routine" in the Ada RM?

Syntax sugar does not bother me. I trust ARG to introduce a couple of 
reserved words in the most annoying way... (:-))

> So is your problem only that using OS threads is less "efficient" than 
> switching and scheduling threads of control in the run-time system?

This too. However the main purpose is control inversion caused by 
callback architectures. A huge number of libraries are built on that 
pattern. This OK for the library provider because it is the most natural 
and efficient way. For the user implementing his own logic, be it 
communication protocol, GUI etc, it is a huge architectural problem as 
it distorts the problem space logic. So the goal is to convert a 
callback/event driven architecture into plain control flow.

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

In Ada 83 there was no way to pass a procedure as a parameter. We used a 
task instead... (:-))

But sure, a possibility to delegate a callback to an entry call without 
intermediates is certainly welcome.

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


Dmitry A. Kazakov

  reply	other threads:[~2023-02-13 15:10 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-07 20:29 Broadcast / iterate to all Connection objects via Simple Components? A.J.
2023-02-08  8:55 ` Dmitry A. Kazakov
2023-02-08  9:55 ` Jeffrey R.Carter
2023-02-13  7:28   ` Emmanuel Briot
2023-02-13  8:30     ` Dmitry A. Kazakov
2023-02-13  8:44       ` Emmanuel Briot
2023-02-13 10:55         ` Dmitry A. Kazakov
2023-02-13 11:07           ` Emmanuel Briot
2023-02-13 11:57             ` Dmitry A. Kazakov
2023-02-13 13:22               ` Niklas Holsti
2023-02-13 15:10                 ` Dmitry A. Kazakov [this message]
2023-02-13 16:26                   ` Niklas Holsti
2023-02-13 19:48                     ` Dmitry A. Kazakov
2023-02-15  9:54                       ` Niklas Holsti
2023-02-15 10:57                         ` Dmitry A. Kazakov
2023-02-15 18:37                           ` Niklas Holsti
2023-02-19  1:27                             ` A.J.
2023-02-19  8:29                               ` Dmitry A. Kazakov
2023-02-19 14:37                               ` Niklas Holsti
2023-02-13 15:43                 ` J-P. Rosen
2023-02-13 16:40             ` Jeremy Grosser <>
2023-02-13 20:33 ` Daniel Norte de Moraes
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox