[Python-ideas] An alternate approach to async IO
Guido van Rossum
guido at python.org
Wed Nov 28 16:59:04 CET 2012
OK, now I see. (I thought that was how everyone was using IOCP.
Apparently not?) However, the "short busy wait" worries me. What if
your app *doesn't* get a lot of requests?
Isn't the alternative to have a "thread pool" with just one thread,
which runs all the Python code and gets woken up by IOCP when it is
idle and there is a new event? How is Trent's proposal an improvement?
On Wed, Nov 28, 2012 at 4:07 AM, Sturla Molden <sturla at molden.no> 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.
>
> Sturla
>
>
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
--
--Guido van Rossum (python.org/~guido)
More information about the Python-ideas
mailing list