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!2.eu.feeder.erje.net!feeder.erje.net!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: Mon, 13 Feb 2023 18:26:07 +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 q1ZcvmChZ3aEsaHoFpog3w++BWLh39EP2Mnsa34NKejLWU7W4L Cancel-Lock: sha1:GEM62ryn5TelF3sR5/wUTzU5LMc= 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:64917 List-Id: On 2023-02-13 17:10, Dmitry A. Kazakov wrote: > On 2023-02-13 14:22, Niklas Holsti wrote: >> On 2023-02-13 13:57, Dmitry A. Kazakov wrote: > >>> I have an impression that ARG's view on co-routines totally ignores >>> the use case of communication stacks and other cases state machines >>> show their ugly faces... >> >> So your co-routines would (1) have their own stack and (2) be >> independently schedulable, which implies (3) having their own >> execution context (register values, instruction pointer, etc.) > > Sure. You should be able to implement communication logic in a natural way: > > 1. Read n bytes [block until finished] > 2. Do things > 3. Write m bytes [block until finished] > 4. Repeat Agreed. >> How is that different from the Ada concept of a "task"? > > It is no different, that the whole point of deploying high level > abstraction: task instead of low level one: state machine. > >> How could the ARG separate between a "task" and a "co-routine" in the >> Ada RM? > > Syntax sugar does not bother me. I trust ARG to introduce a couple of > reserved words in the most annoying way... (:-)) 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. 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. That could be one way to identify the co-routines that are to be executed by one and the same "real" task, as you propose. What properties do you propose for co-routines that would not hold for ordinary tasks? >> So is your problem only that using OS threads is less "efficient" than >> switching and scheduling threads of control in the run-time system? > > This too. But you cannot ask the ARG to define co-routines as being "like tasks but more efficient". :-) > 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"?