iozone compilation failure with uclibc due to aio

[Rich Felker]

On Mon, Dec 10, 2012 at 09:56:38PM +0100, Laurent Bercot wrote:
> > As far as I know, uClibc does not implemnt the AIO part of POSIX. Is
> > there perhaps any way to make iozone use some fallback in place of
> > AIO? It's not like POSIX AIO is a particularly well-designed API that
> > anybody would actually WANT to use...
> 
>  Hello Rich,
>  From a purely theoretical/academic point of view, as a software
> engineer, I'm interested in knowing the details of why you think AIO
> is badly designed. Not saying I disagree (I've never used that part of
> POSIX so I don't know it enough to have an opinion), I'd just like to
> hear your arguments about it.

Perhaps my opinion is influenced by the ugliness and broken corner
cases that arise trying to implement it in userspace on top of
orginary POSIX IO functions and threads. See the glibc bug I just
submitted, #14942:

http://sourceware.org/bugzilla/show_bug.cgi?id=14942

In fairness, our implementation in musl is at present just as broken
as glibc's and probably more broken.

Still, I think there's a lot of ugliness inherent in the API. Some
things that come to mind:

1. Having to submit your requests with a structure containing the
arguments rather than with function arguments. It would be better if
the arguments (like fd, offset, etc.) were actual function arguments
and you got back an opaque handle for the request (rather than having
internal stuff hidden in the non-opaque aiocb buffer). This can of
course be "fixed" by wrapping the API, so it's not a huge issue.

2. Use of sigevent for completion-notification. SIGEV_THREAD has a lot
of flaws that make it virtually impossible to use correctly, so you're
stuck with signals, which involve nasty global state and aren't
library-safe. This is more a complaint about sigevent's poor
specification in general than about AIO in particular, but it's pretty
much a show-stopper if you want asynchronous delivery of completion
notification in a library; it certainly crosses the point at which it
becomes easier, safer, AND cleaner to just "roll your own" async IO
using threads.

3. Underspecified corner-cases, like whether there's any ordering
between AIO requests on different file descriptors that refer to the
same underlying open file description or even just the same underlying
file (with a different open file description).

>  If it's too off-topic for the list, we can take the discussion to
> private, but I believe other readers could be interested in it too.

I don't think it's too off-topic. Certainly if this feature is to be
added to uClibc, there should be an understanding of what's ugly about
it and what makes it so difficult to get right.

Rich