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"?
next prev parent 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