From nobody Sun Jan 14 00:35:30 2024 X-Original-To: freebsd-threads@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TCGXB0NCcz573RZ for ; Sun, 14 Jan 2024 00:35:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TCGX95pBlz4n0Z; Sun, 14 Jan 2024 00:35:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.17.1/8.17.1) with ESMTP id 40E0ZUaG023212; Sun, 14 Jan 2024 02:35:33 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 40E0ZUaG023212 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 40E0ZUlu023211; Sun, 14 Jan 2024 02:35:30 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 14 Jan 2024 02:35:30 +0200 From: Konstantin Belousov To: Alan Somers Cc: =?utf-8?B?Vmluw61jaXVz?= dos Santos Oliveira , freebsd-threads@freebsd.org, Konstantin Belousov Subject: Re: aio_read2() and aio_write2() Message-ID: References: List-Id: Threading List-Archive: https://lists.freebsd.org/archives/freebsd-threads List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED,URIBL_SBL_A autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4TCGX95pBlz4n0Z X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] On Sat, Jan 13, 2024 at 05:23:43PM -0700, Alan Somers wrote: > On Sat, Jan 13, 2024 at 4:46 PM Vinícius dos Santos Oliveira > wrote: > > > > Em sáb., 13 de jan. de 2024 às 19:18, Alan Somers > > escreveu: > > > I'm not on this mailing list, but I saw kib's code review and I have > > > some comments > > > > > > > Can we have some aio_read() function that ignores aio_offset (i.e. the current file position is used)? I'm trying to port libboost's ASIO file support to FreeBSD, and I stumbled upon this limitation. > > > > > > The fundamental problem with using the file's seek offset with AIO is > > > that multiple operations may be in-flight at any one time that depend > > > on the seek offset, and there's nothing that enforces their ordering. > > > > That's not different from creating two threads and calling read() from > > both threads in parallel. The kernel can do nothing to prevent bugs in > > userspace applications. It's already possible to violate ordering > > using threads. > > > > > How does boost.asio address this problem? > > > > You don't address this problem. Applications doing this are buggy. > > io_uring in Linux doesn't address this problem. IOCP in Windows does > > give a few guarantees, but for now I'd argue against it. > > > > Applications shouldn't start a second stream operation when the last > > one hasn't even finished yet. > > If you shouldn't start a second stream until the first has finished, > the what is the reason for using AIO? This doesn't sound like a good > application for AIO to me. I suspect that ultimately this feature is for some variant of the green threads (not the word 'reactive' appeared somewhere in the communications). The feature allows to offload the blocking io to different context, leaving the current thread context on CPU. With such scenario, it is clear that 'forwarded' read() operations should be already correctly ordered by the caller. In principle the function of the new flag could be done like aio.aio_offset = lseek(fd, 0, SEEK_CUR); aio_read(&aio); with the dis-advantage of requiring two syscalls instead of one. > > > > > > Are its operations completed in a strict sequence? > > > > When the kernel dispatches completion events (SIGEV_KEVENT/EVFILT_AIO) > > to the process, Boost.Asio will route them to the correct module > > within the program (the one that started the associated operation). > > The program can retain ordering by only scheduling new operations when > > the last one finished. Boost.Asio by itself will act just as a > > portable layer between the program and the OS. Boost.Asio won't by > > itself give any sequencing guarantee. > > > > Ordering problems can happen even if you only use kqueue with a single > > thread. Here's an example from the real-world: > > https://sourceforge.net/p/asio/mailman/asio-users/thread/5357B16C.6070508%40mail1.stofanet.dk/ > > (keep reading past the multi-threading problems) > > > > Here's a condensed explanation for what happened in the example: > > https://docs.emilua.org/api/0.6/tutorial/streams.html#composed-operations > > > > -- > > Vinícius dos Santos Oliveira > > https://vinipsmaker.github.io/