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 _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc