On Oct 19, 2010, at 9:55 PM, firstname.lastname@example.org wrote:
Not only is the performance usually worse than expected, the behavior of aio_* functions require all kinds of subtle and mysterious coordination with signal handling, which I'm not entirely sure Python would even be able to pull off without some modifications to the signal module. (And, as Jean-Paul mentioned, if your OS kernel runs out of space in a queue somewhere, completion notifications might just never be delivered at all.)
Just to be clear, James corrected me there. I thought Jesus was talking about the mostly useless Linux AIO APIs, which have the problems I described. He was actually talking about the POSIX AIO APIs, which have a different set of problems making them a waste of time.
I know, I'm referring to the behavior of POSIX AIO.
Perhaps I'm overstating the case with 'subtle and mysterious', then, but the POISX 'aiocb' structure still includes an 'aio_sigevent' member which is the way to find out about I/O event completion. If you're writing an application that uses AIO, basically all of your logic ends up living in the context of a signal handler, and as http://www.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_04.html#tag_02_04_01 puts it,
"When signal-catching functions are invoked asynchronously with process execution, the behavior of some of the functions defined by this volume of IEEE Std 1003.1-2001 is unspecified if they are called from a signal-catching function."
Of course, you could try using signalfd(), but that's not in POSIX.
(Or, you could use SIGEV_THREAD, but that would be functionally equivalent to running read() in a thread, except much more difficult.)