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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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