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: Mon, 13 Feb 2023 15:22:19 +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: 8bit X-Trace: individual.net O1cV5BC++dPljp5FqJ/S8AiaIDd91vPsHBiJ+P1tl4xSbxD4jW Cancel-Lock: sha1:zxjU5OIc7eKPDrgXkgQf6CHvK+M= 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:64914 List-Id: On 2023-02-13 13:57, Dmitry A. Kazakov wrote: > On 2023-02-13 12:07, Emmanuel Briot wrote: >> On Monday, February 13, 2023 at 11:55:10 AM UTC+1, Dmitry A. Kazakov >> wrote: [ snip discussion of network programming details, retain discussion about co-routines ] >>> I'd like to have special Ada "tasks" acting as co-routines on top of >>> proper tasks yielding when the socket buffer is empty or full. >> >> This is an approach we had discussed at AdaCore before I left.  There >> are multiple drawbacks >> here: the limited stack size for tasks by default (2MB), the fact that >> entries cannot return indefinite >> types, the fact that currently those tasks are assigned to OS threads >> (so too many of them does >> impact resource usage),... > > My idea is to have these as pseudo-tasks scheduled by the Ada run-time > and not mapped onto any OS threads. A proper thread would pick up such a > task and run it until it yields. The crucial point is to use the stack > of the pseudo-task in place of the thread's stack or backing it up and > cleaning the portion of the stack at the point of yielding, whatever. > >> A colleague had found an external library that would provide several >> stacks and thus let people >> implement actual co-routines.  We did not do much more work on that, >> but it was a nice proof >> of concept, and efficient.  I think things are mostly blocked now, as >> the ARG has been discussing >> these topics for quite a few years now. > > 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.) How is that different from the Ada concept of a "task"? How could the ARG separate between a "task" and a "co-routine" in the Ada RM? There exist Ada compilers and run-times where the tasking concept is implemented entirely in the run-time system, without involving the underlying OS (if there even is one). That approach was mostly abandoned in favour of mapping tasks to OS threads, which makes it easier to use potentially blocking OS services from tasks without blocking the entire Ada program. So is your problem only that using OS threads is less "efficient" than switching and scheduling threads of control in the run-time system? 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. 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.