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 16:10:15 +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 15:10:14 -0000 (UTC) Injection-Info: reader01.eternal-september.org; posting-host="92cb98c895259fadeb1c55267e115d73"; logging-data="2295667"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+bTK4tTSzF04JHTZf+nEa1jRzI+9KjII4=" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Cancel-Lock: sha1:/UkQG2Dw8dwYbhuAQKphJoSBBqA= Content-Language: en-US In-Reply-To: Xref: reader01.eternal-september.org comp.lang.ada:64915 List-Id: 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 > 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... (:-)) > 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. 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. > If > so, that seems to be a quality-of-implementation issue that could be > solved in a compiler-specific way, and not an issue with the Ada > language itself. In Ada 83 there was no way to pass a procedure as a parameter. We used a task instead... (:-)) But sure, a possibility to delegate a callback to an entry call without intermediates is certainly welcome. > The point (from Emmanuel) that task entries cannot return indefinite > types is certainly a language limitation, but seems to have little to do > with the possible differences between tasks and co-routines, and could > be addressed on its own if Ada users so desire. Yes. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de