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.0 required=3.0 tests=BAYES_40,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Received: by 2002:a0c:f48f:0:b0:56e:9dfa:b0a5 with SMTP id i15-20020a0cf48f000000b0056e9dfab0a5mr531060qvm.1.1676306406216; Mon, 13 Feb 2023 08:40:06 -0800 (PST) X-Received: by 2002:a05:6870:580d:b0:163:31fe:9bd with SMTP id r13-20020a056870580d00b0016331fe09bdmr3519232oap.129.1676306405758; Mon, 13 Feb 2023 08:40:05 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.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 08:40:05 -0800 (PST) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=2604:4080:1147:8031:c88a:6fff:fef8:3cb1; posting-account=W6eUXQoAAAByI_bBpxN1fQnFpJiNZtBw NNTP-Posting-Host: 2604:4080:1147:8031:c88a:6fff:fef8:3cb1 References: <392dd5d3-4df1-403f-b703-ee6f750dbc81n@googlegroups.com> <02802bf3-fc29-44da-bd79-21f26d122203n@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <824809a6-8815-489b-b752-203bf6c09209n@googlegroups.com> Subject: Re: Broadcast / iterate to all Connection objects via Simple Components? From: "Jeremy Grosser " Injection-Date: Mon, 13 Feb 2023 16:40:06 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 4397 Xref: reader01.eternal-september.org comp.lang.ada:64918 List-Id: > epoll is definitely the modern approach on linux, until of course someone= finds=20 > something even better. epoll is fully thread safe too, which is very nice= when=20 > used from Ada.=20 For high performance networking, io_uring [1] is the new kid on the block, = but the API involves a scary amount of pointer manipulation, so I'm not con= vinced that it's safe to use yet. While epoll is thread safe, there are some subtleties. If you register a li= stening socket with epoll, then call epoll_wait from multiple threads, more= than one thread may be woken up when the socket has a waiting incoming con= nection to be accepted. Only one thread will get a successful return from a= ccept(), the others will return EAGAIN. This wastes cycles if your server h= andles lots of incoming connections. The recently added (kernel >=3D4.5) EP= OLLEXCLUSIVE flag enables a mutex that ensures the event is only delivered = to a single thread. > They also have strong concerns about platform-agnostic support, and epoll= is linux-specific=20 > at this point (likely also BSD). There exists multiple libraries out ther= e that provide an API=20 > common to multiple platforms, and that use epoll on linux. Maybe that's w= hat would make=20 > sense, but nowadays with Alire, I would expect someone to build a crate t= here rather than=20 > AdaCore modify GNAT.Sockets. On BSD, the kqueue [2] API provides similar functionality to epoll. I belie= ve kqueue is a better design, but you use what your platform supports. libev [3] is the library I see used most commonly for cross-platform evente= d I/O. It will use the best available polling syscalls on whatever platform= it's compiled for. Unfortunately, it's composed mostly of C preprocessor m= acros. I've already written an epoll binding [5] that's in the Alire index. GNAT.S= ockets provides the types and bindings for the portable syscalls. For the Protohackers puzzles, I've written a small evented I/O server using= those bindings [6]. Note that this server does not use events for the send= () calls yet, which may block, though in practice it isn't an issue with th= e size of the payloads used in this application. I do plan to refactor this= to buffer data to be sent when the Writable (EPOLLOUT) event is ready. So far, I've found tasks and coroutines to be unnecessary for these servers= , though coroutines would make it possible to implement Ada.Streams compati= ble Read and Write procedures, providing a cleaner interface that doesn't e= xpose callbacks to the user. [1] https://lwn.net/Articles/776703/ [2] https://people.freebsd.org/~jlemon/papers/kqueue.pdf [3] https://linux.die.net/man/3/ev [4] https://github.com/JeremyGrosser/epoll-ada [5] https://github.com/JeremyGrosser/protohackers/blob/master/src/mini.adb