Date: Sat, 13 Jan 2024 20:46:06 -0300 From: =?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?= <vini.ipsmaker@gmail.com> To: Alan Somers <asomers@freebsd.org> Cc: freebsd-threads@freebsd.org, Konstantin Belousov <kib@freebsd.org> Subject: Re: aio_read2() and aio_write2() Message-ID: <CAK9RveJLK9uU0twM%2BKznUNnUnsqzwoqidPN8dzNptMQ50Z7r1Q@mail.gmail.com> In-Reply-To: <CAOtMX2haq%2BErvqD2PDYKUGRgdCrk2SDjtoPL-W5jR8q8_4denA@mail.gmail.com> References: <CAOtMX2haq%2BErvqD2PDYKUGRgdCrk2SDjtoPL-W5jR8q8_4denA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Em s=C3=A1b., 13 de jan. de 2024 =C3=A0s 19:18, Alan Somers <asomers@freebsd.org> 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 sup= port 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. > 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%4= 0mail1.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 --=20 Vin=C3=ADcius dos Santos Oliveira https://vinipsmaker.github.io/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAK9RveJLK9uU0twM%2BKznUNnUnsqzwoqidPN8dzNptMQ50Z7r1Q>