This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author dabeaz
Recipients brian.curtin, dabeaz, giampaolo.rodola, jcea, pitrou
Date 2011-02-05.14:54:41
SpamBayes Score 1.3368795e-09
Marked as misclassified No
Message-id <1296917682.66.0.864908636788.issue11117@psf.upfronthosting.co.za>
In-reply-to
Content
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 :-).
History
Date User Action Args
2011-02-05 14:54:42dabeazsetrecipients: + dabeaz, jcea, pitrou, giampaolo.rodola, brian.curtin
2011-02-05 14:54:42dabeazsetmessageid: <1296917682.66.0.864908636788.issue11117@psf.upfronthosting.co.za>
2011-02-05 14:54:41dabeazlinkissue11117 messages
2011-02-05 14:54:41dabeazcreate