From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-3.2 required=3.0 tests=BAYES_00,NICE_REPLY_A, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader01.eternal-september.org!news.szaf.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Broadcast / iterate to all Connection objects via Simple Components? Date: Wed, 15 Feb 2023 11:54:33 +0200 Organization: Tidorum Ltd Message-ID: References: <392dd5d3-4df1-403f-b703-ee6f750dbc81n@googlegroups.com> <02802bf3-fc29-44da-bd79-21f26d122203n@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net 8jRCDIJ9K+kcK/4QCKo1iQKjPG7ZJ/z3M890WWbL/Nkb16tGEY Cancel-Lock: sha1:c9/b4Mvfqan5jeze/X1UzXaO7pg= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Content-Language: en-US In-Reply-To: Xref: reader01.eternal-september.org comp.lang.ada:64934 List-Id: 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?