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

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

On 2023-02-13 09:44, Emmanuel Briot wrote:
>> sockets (socket select).
> 
> Have you taken a look at epoll(), on linux ?

The implementation is on top of GNAT.Sockets, so no.

> It is so much more natural to use, and so much more efficient in practice.
> The example I mentioned above (a server with 25_000 concurrent connections) cannot work with select (which only
> accepts file descriptors up to 1024), and is slow with poll (since the result of the latter is the number of events, and we
> need to iterate over all registered sockets every time).

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... (:-))

>> P.S. This poses difficulties for users, who see all communication turned
>> upside down being driven by arbitrary socket events rather than by the
>> protocol logic. This was a reason I argued for introducing co-routines
>> with task interface in Ada.
> 
> In my own code, I basically provide an epoll-based generic framework.  One of the formal parameters is a `Job_Type`
> with one primitive operation `Execute`.
> The latter is initially called when a new connection is established, and is expected to do as much non-blocking work
> as it can (Execute is run in one of the worker tasks).  When it cannot make progress, it returns a tuple (file_descriptor, type_of_event_to_wait_for)
> to indicate when it needs to be called again in the future, for instance some data became available to read on the
> specified file_descriptor.
> The intent is that the `Job_Type` is implemented as a state machine internally.

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.

> Of course, a state machine is one of the two ways I know (along with a task) to implement the equivalent of
> a co-routine in Ada.  So I 100% agree with you that co-routines would be very useful in simplifying user code,
> in particular in the scenario we are discussing here !

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.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de