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 12:57:19 +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 11:57:19 -0000 (UTC) Injection-Info: reader01.eternal-september.org; posting-host="0a446d501ac53ea3fdfc7027a586d37f"; logging-data="2208201"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/CrV+7Jm3wEWvejW8OcBq+vq0t+dFW4kU=" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Cancel-Lock: sha1:CYcS7vbnu7wvFozh+415gDh5VC8= In-Reply-To: Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:64913 List-Id: 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: >> Well, if there is Linux kernel level support why it is not used in >> socket select as it is in epoll? I would expect them do that at some >> point or drop epoll... (:-)) > > Because in practice the linux developers don't get to modify such APIs, which > are mandated by Posix, or Unix, or some RFC. > So the API for select and poll will *never* change. Well, the API does not really prescribe the actual implementation of fd_set. If you need that many elements in the set then using a bitmask and not having some bookkeeping to balance load will bit you at some point anyway. > epoll is definitely the modern approach on linux, until of course someone finds > something even better. epoll is fully thread safe too, which is very nice when > used from Ada. > Using select() is totally outdated at this point, and means you can never handle > more than 1000 simultaneous clients, and that only if you do not have other > file descriptors open (database, files,...) Well, it is indicative how outdated Linux always was. Asynchronous I/O was old news long *before* Linus even started his project... (:-)) > The person who developed GNAT.Sockets has left AdaCore a while ago, so "they" (which > I assume is what your message was referring to) are actually unlikely to update that. Yes, that is what I expect, a face lifting of Linux implementation of GNAT.Sockets. > They also have strong concerns about platform-agnostic support, and epoll is linux-specific > at this point (likely also BSD). GNAT.Sockets is no thin bindings, I see little problem here. AFAIK BSD allows increasing FD_SETSIZE, but I am not sure. > There exists multiple libraries out there that provide an API > common to multiple platforms, and that use epoll on linux. Maybe that's what would make > sense, but nowadays with Alire, I would expect someone to build a crate there rather than > AdaCore modify GNAT.Sockets. That is an option too. However presently I cannot use Alire because last time I looked it did not support automated uploading, versioning and target dependencies through the GPR. >> 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... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de