On 22/01/2009 9:38 AM, Brad Johnson wrote:
However, while it is waiting for the
GIL in the UI thread (when the worker thread has it), it is locked into a
WaitForSingleObject call (some layers below PyGILState_Ensure).
Obviously the GIL can only be held by one thread at a time. The
question then is why your worker thread isn't periodically releasing the
GIL so the UI thread can grab it.
I think this is the key. Since my application embeds Python, I call
PyGILState_Ensure in the worker thread to acquire the GIL before doing anything
related to Python.
And you release it at the end, correct?
I understand Python releases the GIL periodically, but could
my call be overriding that? If so, how can I run any Python code and hope to
allow other threads to take a stab at getting the GIL?
So one your thread has acquired the GIL, one of 3 things happens:
* It returns quickly and the GIL is released.
* It executes many many instructions: every 'n' instructions Python will
temporarily release the GIL for you.
* It calls some other blocking function. This other blocking function
must release the GIL before blocking, then re-aquire it when it needs to
re-enter Python.
Each of those 3 scenarios allows the other thread to run. You need to
identify which of the 3 your thread falls into - I suspect it will end
up being the final one, and the blocking functions do *not* release the
GIL (note that all COM calls you make on any thread *will* release the
GIL before making the actual call - it is more likely to be some
function *you* expose to Python in a module or similar?
Cheers,
Mark
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
