Re: aio_read2() and aio_write2()

On Sat, Jan 13, 2024 at 4:46 PM Vinícius dos Santos Oliveira
<vini.ipsmaker@gmail.com> wrote:
>
> Em sáb., 13 de jan. de 2024 às 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 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.

>
> > 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/