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 11:55:07 +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 10:55:06 -0000 (UTC) Injection-Info: reader01.eternal-september.org; posting-host="0a446d501ac53ea3fdfc7027a586d37f"; logging-data="2208201"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX189MXNJEeVaV/ZOFElYTC8Vuc7wv+wr+5A=" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Cancel-Lock: sha1:37+gqT9ttlhRjwHeMvO4jET9hGU= In-Reply-To: <02802bf3-fc29-44da-bd79-21f26d122203n@googlegroups.com> Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:64911 List-Id: 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