Extension libraries, spawned threads, and the global interpreter lock

Damien Elmes resolve at repose.REMOVE.cx
Wed Jan 2 21:16:49 EST 2002


Hi folks,

If I haven't already scared you off with the subject field, please humour me.
I'm still in the beginner to intermediate stages with Python, and I apologise
if the answer to this is in an obvious place.

Basically I'm wrapping an xlib based library that was written by a third party.
I have access to the source. This library spawns two threads to deal with
certain xlib events. The call chain to do this is roughly:

thewrapper() -> 
    
(in C)  wrapper_ext_module_init() ->
        
(in C)      xlib_stuff_init()

and it's in that third function that two threads are spawned.

Now, from my understanding of the docs, the C extension module function which
I've created operates under a global interpreter lock. But the two threads
spawned would not (as the lock would be cleared when the spawning function
returned). 

The problem I'm getting is that C-c when running from the interactive
interpreter is killing python, like so:

reflex$ python
Python 2.1.1+ (#1, Dec 21 2001, 01:01:30) 
[GCC 2.95.4 20011006 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import pyosd
>>>
>>> # this code runs the extension module which spawns the threads
>>> p = pyosd.osd(pyosd.default_font, "white")
>>> 
>>> # now we hit C-c
KeyboardInterrupt
>>> 
KeyboardInterrupt
>>> 
KeyboardInterrupt
>>>
>>> # and again
KeyboardInterrupt

KeyboardInterrupt

KeyboardInterrupt
>>> Segmentation fault

I get similar results when not using the readline module.

If, however, I create a file which sleeps in a try: except block, and I catch
the keyboard interrupt exception, these problems don't surface.

So my question is: am I correct in thinking it's a problem with the GIL not
being held in the other threads?

If so, would explicitly grabbing and freeing the lock in the xlib threads solve
the problem? 

If so, is there a better way? I'd prefer not to have to delve into their
source.

I hope I've been coherent. If anyone could offer any suggestions, I'd really
appreciate it.

-- 
Damien Elmes
resolve at repose.REMOVE.cx
Usenet replies are fine, please parse my email address if you
want to send directly.





More information about the Python-list mailing list