Re: aio_read2() and aio_write2()

Em dom., 14 de jan. de 2024 às 14:13, Alan Somers
<asomers@freebsd.org> escreveu:
> The problem is that this flag would be almost impossible to use
> correctly for the intended use cases of POSIX AIO.  Your application
> is actually pretty unusual in that it only has one operation in-flight
> at a time.  I think it would be better to use the lseek solution
> rather than add a footgun to POSIX AIO.

There are two things here: Boost.Asio, and applications built on top
of Boost.Asio. I can't speak for other applications built on top of
Boost.Asio. With that in mind, let me proceed.

There is nothing unusual about my application. I just built an
execution context that implements the green threading model. That's
nothing unusual about that. NodeJS, Python's asyncio, Rust's asyncio,
Golang, luvit, and so on and so on. All these frameworks just mimic
interfaces from the blocking world (e.g. two threads doing a blocking
read() on two different files become two fibers doing a read() within
the same thread). If anything, the whole world is moving to this model
after NodeJS proved its usefulness. So what's unusual about that?

To clarify: I don't have a single in-flight operation at a time. The
same thread dispatches IO requests for different streams (sockets and
files). AIO is not only useful for batching operations (on the same
file). AIO is also useful for a batch of IO operations on different
files. File IO is always “ready” and the readiness model doesn't work
for files. On Linux, I can just use io_uring (proactor/completion
model) for everything (as in it won't prevent me from skipping an
explicit offset). Same with Windows (IOCP). What is special about
FreeBSD here?

POSIX AIO by itself is useless to me. It's only useful to me with BSD
extensions (SIGEV_KEVENT for kqueue integration). I don't see a reason
why it can't have another small extension that is pretty much
non-invasive.


-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/