Home Original page

Determining if any threads are waiting for GIL

Rouslan Korneychuk rouslank at msn.com
Thu Dec 20 01:54:01 EST 2012 
I'm working on a package that can compile CPython byte-code into native 
machine code (so far: x86 and x86_64 are supported). I have support for 
almost every byte-code instruction implemented already, but to fully 
emulate the interpreter, I need an efficient way to determine two 
things: when to give up the global interpreter lock (GIL) so another 
thread can use it, and if there are any asynchronous calls pending (a la 
Py_AddPendingCall).

The interpreter loop does this by polling a pair of boolean values 
(technically there is a third value it polls first as an optimization, 
but this is not important), but these values are not exposed by the API 
in any way. Even if I just implement context switching between compiled 
code only, I would still need a way to determine if there are pending 
asynchronous calls. The whole point of this package is to speed up 
Python programs, so unconditionally calling Py_MakePendingCalls every 
once in a while is unacceptable.

So far the only solution I have come up with is to implement a basic 
machine code interpreter that would parse PyEval_AcquireLock and 
Py_AddPendingCall at run-time to determine the addresses of the values 
the Python interpreter uses. I wouldn't need to fully parse the machine 
code since for most instructions, I just need to figure out how long it 
is so I can skip over it, but with varying compilers and build settings, 
this would be opening up a can of worms.

Any suggestions are welcome.
More information about the Python-list mailing list