On Oct 19, 2010, at 9:55 PM, exar...@twistedmatrix.com 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.)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
