[Python-ideas] An alternate approach to async IO

[Sturla Molden]

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.

Sturla