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.8 required=3.0 tests=BAYES_50,FREEMAIL_FROM, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Received: by 2002:ac8:5ac8:0:b0:3b8:629e:68a7 with SMTP id d8-20020ac85ac8000000b003b8629e68a7mr3019590qtd.321.1676277842249; Mon, 13 Feb 2023 00:44:02 -0800 (PST) X-Received: by 2002:a05:6808:190e:b0:37d:7a78:ba4a with SMTP id bf14-20020a056808190e00b0037d7a78ba4amr690269oib.41.1676277841941; Mon, 13 Feb 2023 00:44:01 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!border-1.nntp.ord.giganews.com!border-2.nntp.ord.giganews.com!nntp.giganews.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 00:44:01 -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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <02802bf3-fc29-44da-bd79-21f26d122203n@googlegroups.com> Subject: Re: Broadcast / iterate to all Connection objects via Simple Components? From: Emmanuel Briot Injection-Date: Mon, 13 Feb 2023 08:44:02 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader01.eternal-september.org comp.lang.ada:64910 List-Id: > sockets (socket select). Have you taken a look at epoll(), on linux ? 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). > 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. 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 !