comp.lang.ada
 help / color / mirror / Atom feed
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Subject: Re: Broadcast / iterate to all Connection objects via Simple Components?
Date: Mon, 13 Feb 2023 18:26:07 +0200	[thread overview]
Message-ID: <k4v6kvFnmrgU1@mid.individual.net> (raw)
In-Reply-To: <tsdjsm$261rj$1@dont-email.me>

On 2023-02-13 17:10, Dmitry A. Kazakov wrote:
> 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


Agreed.


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


But why should the RM define two "task" concepts that have exactly the 
same properties? Or should co-routines have some different properties? 
That was the point of my question, apologies if I was unclear.

For example, co-routines could have the ability to form some kind of 
"mutually exclusive groups" such that there would be no need for 
mutual-exclusion controls such as protected objects between co-routines 
in the same group. That could be one way to identify the co-routines 
that are to be executed by one and the same "real" task, as you propose.

What properties do you propose for co-routines that would not hold for 
ordinary tasks?


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


But you cannot ask the ARG to define co-routines as being "like tasks 
but more efficient". :-)


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


Yes, yes. But tasks can do that. How would co-routines help, aside from 
perhaps being "more efficient"?

  reply	other threads:[~2023-02-13 16:26 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
2023-02-13 16:26                   ` Niklas Holsti [this message]
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 <jeremy@synack.me>
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