[Python-ideas] An alternate approach to async IO

[Trent Nelson]

On Wed, Nov 28, 2012 at 04:07:22AM -0800, Sturla Molden wrote:
> 
> Den 28. nov. 2012 kl. 03:59 skrev Guido van Rossum <guido at python.org>:
> 
> > 
> > Then why not just have one thread?
> 
> Because of the way IOCPs work on Windows: A pool of threads is waiting
> on the i/o completion port, one thread from the pool is woken up on
> i/o completion. There is nothing to do about that, it is an event
> driven thread pool by design. 
> 
> The question is what a thread woken up on io completion shold do. If
> it uses the simplified GIL API to ensure the GIL, this would mean
> excessive GIL shifting with 64k i/o tasks on a port: Each time one of
> the 64k tasks is complete, a thread would ensure the GIL. That is
> unlikely to be very scalable.
> 
> So what Trent suggested is to just have these threads enqueue some
> data about the completed task and go back to sleep.
> 
> That way the main "Python thread" would never loose the GIL to a
> thread from the IOCP. Instead it would shortly busy-wait while a
> completed task is inserted into the queue. Thus synchronization by the
> GIL is replaced by a spinlock protecting a queue (or an interlocked
> list on recent Windows versions).
> 
> > 
> >> 2. It potentially keeps the thread that runs the CPython
> >> interpreter in cache, as it is always active. And thus it also
> >> keeps the objects associated with the CPython interpreter in cache.
> > 
> > So what code runs in the other threads? I think I'm confused...
> 
> Almost nothing. They sleep on the IOCP, wake up on i/o completion,
> puts the completed task in a queue, and goes back to waiting/sleeping
> on the port. But they never attempt to acquire the GIL.

    Couldn't have said it better myself.  Nice to have you on board
    Sturla ;-)

        Trent.