Threading a lengthy C function

Leo Breebaart leo at lspace.org
Thu Nov 20 07:49:32 EST 2003


Hi all,

In a GUI program I'm currently developing (wxWindows, if that
matters), I am trying to get some time-consuming tasks (triggered
by e.g. the user choosing a menu item) out of the interface
thread and into 'worker' threads of their own, in order to stop
them from locking up the GUI.


If I subclass threading.Thread, and I override run() as follows:

    def run(self):
      retvalue = time.sleep(50)

then everything works perfectly fine when I start up this Thread
in response to the user trigger -- the GUI unlocks and the
application windows will repaint correctly, etc.

If, however, I use the kind of run() method that I *really* need:

    def run(self):
      retvalue = mypackage.sleep(50)

where mypackage.sleep() is in fact a SWIG-generated wrapper
around the C library sleep() function, I have no such luck: the
entire application will *still* lock up completely until this
task is done.

My guess would be (but I'm new to Python, so I may be entirely
wrong) that this has something to do with that Global Interpreter
Lock thing I keep reading about. I can imagine that if my lengthy
task is a Python task, the interpreter will get the chance to
switch between threads, but that if the task is an external C
function, this will be executed 'atomically' with no chance for
the interpreter to release the GIL to other threads.

I'd like to know if this interpretation of what's happening is
correct (or if it isn't, then what is?), but most importantly I
was wondering if anybody could point me in the direction of a
solution or workaround to my actual problem.

Many thanks in advance,

-- 
Leo Breebaart  <leo at lspace.org>




More information about the Python-list mailing list