[Python-ideas] An alternate approach to async IO

[Richard Oudkerk]

On 27/11/2012 5:49pm, Trent Nelson wrote:
>      Here's the "idea" I had, with zero working code to back it up:
>      what if we had a bunch of threads in the background whose sole
>      purpose it was to handle AIO?  On Windows/AIX, they would poll
>      GetQueuedCompletionStatus, on Solaris, get_event().
>
>      They're literally raw pthreads and have absolutely nothing to
>      do with Python's threading.Thread() stuff.  They exist solely
>      in C and can't be interfaced to directly from Python code.
>
>      ....which means they're free to run outside the GIL, and thus,
>      multiple cores could be leveraged concurrently.  (Only for
>      processing completed I/O, but hey, it's better than nothing.)
>
>      The threads would process the completion port events via C code
>      and allocate necessary char * buffers on demand.  Upon completion
>      of their processing, let's say, reading 4096 bytes from a socket,
>      they push their processed event and data to an interlocked* list,
>      then go back to GetQueuedCompletionStatus/get_event.

But you have to allocate the buffer *before* you initiate an overlapped 
read.  And you may as well make that buffer a Python bytes object (which 
can be shrunk if it is too large).  That leaves no "processing" that can 
usefully be done by a C level thread pool.

Also, note that (at least on Windows) overlapped IO automatically makes 
use of a hidden thread pool to do the IO.

-- 
Richard