This issue is a placeholder for exposing Async IO thru Python.

The relevant mail thread is at:

http://mail.python.org/pipermail/python-dev/2010-October/104770.html


Relevant resources:

http://feedproxy.google.com/~r/Wwwc0t0d0s0org/~3/snM0BJ8evv4/7147-Synchronicity-in-asynchronicity.html

http://www.opengroup.org/onlinepubs/000095399/basedefs/aio.h.html

From the python-dev thread:

http://mail.python.org/pipermail/python-dev/2010-October/104782.html

“os._exit is useful. os.open is useful. aio_* are *not* useful. For anything. If there's anything you think you want to use them for, you're wrong. It either won't work properly or it will worse performing than the simpler alternatives.”

http://mail.python.org/pipermail/python-dev/2010-October/104786.html

“I'd like to echo this sentiment.  This is not about providing a 'safe' wrapper to hide some powerful feature of these APIs: the POSIX aio_* functions are really completely useless.

[...]

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.)”

Anyone contemplating the use of aio_ functions should first go read "The Story of Mel".

http://www.catb.org/jargon/html/story-of-mel.html

Thanks, David, for the link. The story is really touching :-).

Glad you liked it!   I think there is a bit of a cautionary tale in there though. With aio_, there is the promise of better performance, but you're also going to need a *LOT* of advance planning and thought to avoid creating a tangled coding nightmare with it.

Just as an aside, one of the uses of aio_ related functions is to implement parts of user-level thread libraries in C (e.g., pthreads, etc.). A library might use the asynchronous I/O callbacks as part of implementing non-kernel (green) threads.  The code for doing this tends to be very low level and hairy with lots of signal handling--for example, if you want to context-switch between two user-level threads in C, you usually do it inside a signal handler (i.e., you thread-switch inside the signal handler called in response to aio_ completions). 

Whether it's feasible to expose aio_* all the way up to Python or not is an open question. I suspect it will be fraught with lots of tricky issues. In the end, it might just be easier to use threads.  Nevertheless, you'll learn a lot about Python internals by working on this :-).

I guess PEP 3156 covers this, closing this one.