Re: Broadcast / iterate to all Connection objects via Simple Components?

[Emmanuel Briot <briot.emmanuel@gmail.com>]

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.