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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de