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 20:48:37 +0100	[thread overview]
Message-ID: <tse46k$27htv$> (raw)
In-Reply-To: <>

On 2023-02-13 17:26, Niklas Holsti wrote:
> On 2023-02-13 17:10, Dmitry A. Kazakov wrote:

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

Ada has floating-point, fixed-point, universal real implementations of 
the same concept of real number. Why?

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

When exclusion is ensured by the logic of I/O processing, then there is 
no difference. In all other cases a pool of threads could service a pool 
of co-routines.

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

I do not see it that way. The objective is being able to reuse blocking 
code as-is with non-blocking I/O and conversely.

As a simplest case consider a pipeline. There are two tasks at its ends. 
That is a blocking implementation. Now, I want to take both tasks and 
run them as co-routines on the context of a single thread.

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

Rendezvous is asymmetric client-server. In a callback scenario parties 
are equivalent. Each can wait for another. With tasks a protected object 
is usually thrown in to work it around.

The objective is twofold:

1. To simplify "pipeline" stuff. Each side need not to know what the 
other side does or each other. They know the pipeline. The programmer 
should use a call or a timed entry call or a selective accept. I leave 
that open for now.

2. To allow sharing context of a single OS thread. So the term "co-routine."

3. As I said above, the goal is to take plain I/O code (the client) and 
reuse it with no adjustments with a server/provider/consumer in place of 
the OS I/O subsystem.

>> 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"?

It is way too complicated and not reusable (see #1). #2 requires 
language magic. Finally, it is not about more efficient code it is about 
prohibitively inefficient code.

Dmitry A. Kazakov

  reply	other threads:[~2023-02-13 19:48 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
2023-02-13 19:48                     ` Dmitry A. Kazakov [this message]
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