Re: aio_read2() and aio_write2()

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