PyEval_AcquireLock deadlock mystery

[Simon Burton]

AFAICT I am trying to get the GIL
from a thread created outside of python, but a deadlock ensues.

I have tried python 2.2 and 2.3. I am running this on Linux, and have
verified, using a backtrace, that it is the child thread calling
PyEval_AcquireLock. PyGILState_Ensure also deadlocks.

The child thread is created by an audio library (portaudio) to run a callback.

I have written my own test of the basic locking mechanism using
pthread_create, and it all works fine (see below).

I have been using pyrex for all this, re-writing a c coded extension
which works fine with the portaudio thread.

So, I am flumoxed.

What debugging techniques should I now persue ?

Here is the test script:

#################################################

cdef void *start_routine( void * arg ):
PyEval_AcquireLock()
PyThreadState_Swap(ts)
print "I'm in python now!"
PyThreadState_Swap(NULL)
PyEval_ReleaseLock()

cdef pthread_t pth

from time import sleep
PyEval_InitThreads()

cdef PyThreadState * mts
cdef PyThreadState * ts
mts = PyThreadState_Get()
if mts == NULL:
raise Error, "PyThreadState_Get: failed"
ts = PyThreadState_New(mts.interp)
if ts == NULL:
raise Error, "PyThreadState_New: failed"

#start_routine(NULL) # deadlock
sleep(1)
# create our own thread instead of using portaudio's thread
pthread_create( &pth, NULL, start_routine, NULL )
sleep(1)

#############################################


Simon.


--
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com

 

[Simon Burton]

Whoa, this was a tough one. But now i know about --with-pydebug and a few
other things.

Python only releases the GIL every once in a while
and my test code used only one instruction that held the GIL in the main
thread. It dawned on me after watching backtraces of acquire/release
locks of the working/not working versions.

Simon.

--
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com