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: Wed, 15 Feb 2023 11:54:33 +0200	[thread overview]
Message-ID: <k53oepFenq7U1@mid.individual.net> (raw)
In-Reply-To: <tse46k$27htv$1@dont-email.me>

On 2023-02-13 21:48, Dmitry A. Kazakov wrote:
> 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?


Of course because these implementations have /different/ properties, 
suitable for different uses. They are /not/ the same, and their 
differences are defined in the Ada RM.

I am asking you what differences you propose between Ada tasks and your 
Ada co-routines, as they would be defined in the Ada RM (and not as they 
would be implemented in some Ada programming system).

Perhaps you think that those differences are implicit in the term 
"co-routine", but I don't find it so, sorry.


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


Aha, so you are proposing that co-routines would have some other means, 
not protected objects, for symmetric inter-co-routine communication. 
What would that be, perhaps directly shared (unprotected) variables? 
Then you have to ensure that those co-routines are implicitly mutually 
exclusive, right? Or are you suggesting some other form of 
inter-co-routine communication?


> The objective is twofold:


(Actually threefold, it seems :-) )


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


By "pipeline", do you mean an order-preserving stream of data from a 
producer to a consumer? If so, a simple protected queue or buffer 
between producer and consumer tasks implements it.

By leaving the details open, you leave your proposal fuzzy and hard to 
understand.


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


I don't think that property is implicit in the term "co-routine", 
because co-routines can exist even without OS threads.

But most importantly, this property cannot be used to /define/ the 
"co-routine" concept in the Ada RM. That definition may of course be 
/chosen/ so as to /allow/ this implementation.

However, this property is already satisfied for "tasks" in those Ada 
systems that implement tasking in the RTS, without using multiple OS 
threads. So the current definition of Ada "tasks" already allows such 
sharing.


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


And that server/provider/consumer would be what? Ada code in the 
application? Or part of the Ada RTS? Would it have to be aware of all of 
the OS I/O subsystem's services? For example, would it have to know 
about the socket interface to networking?

  reply	other threads:[~2023-02-15  9:54 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
2023-02-15  9:54                       ` Niklas Holsti [this message]
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