Message127994
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 :-). |
|
Date |
User |
Action |
Args |
2011-02-05 14:54:42 | dabeaz | set | recipients:
+ dabeaz, jcea, pitrou, giampaolo.rodola, brian.curtin |
2011-02-05 14:54:42 | dabeaz | set | messageid: <1296917682.66.0.864908636788.issue11117@psf.upfronthosting.co.za> |
2011-02-05 14:54:41 | dabeaz | link | issue11117 messages |
2011-02-05 14:54:41 | dabeaz | create | |
|