By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
439,941 Members | 1,766 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 439,941 IT Pros & Developers. It's quick & easy.

PyEval_AcquireLock deadlock mystery

P: n/a

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

Jul 18 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a

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

Jul 18 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.