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!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Broadcast / iterate to all Connection objects via Simple Components? Date: Mon, 13 Feb 2023 20:48:37 +0100 Organization: A noiseless patient Spider 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 Injection-Date: Mon, 13 Feb 2023 19:48:36 -0000 (UTC) Injection-Info: reader01.eternal-september.org; posting-host="92cb98c895259fadeb1c55267e115d73"; logging-data="2344895"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18RJ4mjYd8yYFGE7Z30L/iW3HD7Dz9hbMM=" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Cancel-Lock: sha1:FYoyOZDHTQuFiRxhwWZ34r7wn+w= In-Reply-To: Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:64919 List-Id: 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