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=-0.5 required=3.0 tests=BAYES_05,FREEMAIL_FROM, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Received: by 2002:a05:622a:47:b0:3ba:1ea6:d99c with SMTP id y7-20020a05622a004700b003ba1ea6d99cmr3052465qtw.405.1676286424919; Mon, 13 Feb 2023 03:07:04 -0800 (PST) X-Received: by 2002:a54:4385:0:b0:37d:74e4:9799 with SMTP id u5-20020a544385000000b0037d74e49799mr982311oiv.63.1676286424534; Mon, 13 Feb 2023 03:07:04 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 13 Feb 2023 03:07:04 -0800 (PST) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=88.160.66.39; posting-account=6yLzewoAAABoisbSsCJH1SPMc9UrfXBH NNTP-Posting-Host: 88.160.66.39 References: <392dd5d3-4df1-403f-b703-ee6f750dbc81n@googlegroups.com> <02802bf3-fc29-44da-bd79-21f26d122203n@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Broadcast / iterate to all Connection objects via Simple Components? From: Emmanuel Briot Injection-Date: Mon, 13 Feb 2023 11:07:04 +0000 Content-Type: text/plain; charset="UTF-8" X-Received-Bytes: 4230 Xref: reader01.eternal-september.org comp.lang.ada:64912 List-Id: 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. 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,...) 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. They also have strong concerns about platform-agnostic support, and epoll is linux-specific at this point (likely also BSD). 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. > Yes, state machine is what I want to avoid. With complex layered > protocols it imposes incredible difficulties requiring auxiliary stacks > and buffers with errors almost intractable either by testing or by > formal proofs. tell me about auxiliary stacks :-) In practice, in my experience, you can have a single incoming buffer which is used by one state, and then another when the first state is no longer active,... so we do not need to have too many buffers, but that definitely is not trivial. Currently, I have a stack of iterators reading from a socket, buffering on top of that, then decompressing LZ4 data, then decoding our binary encoding to Ada values. > 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),... 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.