On 23/01/2009 4:49 AM, Brad Johnson wrote:
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
> 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 f
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
> > 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
On 22/01/2009 3:33 AM, Brad Johnson wrote:
I have embedded the Python interpreter into a COM application. In this
application, I create worker threads that execute Python code.
I marshal some COM objects that live in the UI thread of the application over to
the worker thread and wrap them with E
