We've been trying to beat threading into submission here... We've
come up with a quick test case that displays nondeterministic behavior
here. We want to spawn off a mainloop () thread to handle all event
processing. But to make sure that the mainloop has started before we
begin taking the GTK lock to add windows, etc in the worker thread we
want to have a mutex that gets released after the event handling
thread takes the GTK lock. The Main thread wakes when the event
thread releases this lock and then tries to acquire the GTK lock to
begin making windows. The first thing that should happen in
mainloop() is the release of the GTK lock, after which the Main thread
can acquire the lock and begin doing its work.
This program should execute straight through, but sometimes it hangs.
We turned on some debugging output to help track this down...
Here's the test case...
-------------------------
from gtk import *
from thread import *
class GtkMainThread:
def run (self, mutex):
threads_enter ()
mutex.release ()
print ("released mutex")
mainloop ()
threads_leave ()
class MainThread:
def run (self):
mutex = allocate_lock ()
mutex.acquire ()
start_new_thread (GtkMainThread ().run, (mutex,))
mutex.acquire ()
print ("acquired lock")
threads_enter ()
print ("have gdk lock")
threads_leave ()
MainThread ().run ()
-------------------------
Here's some debugging output:
-------------------------
Correct run:
$ python threads.py
in gtk_init()
currentThread(): no current thread for 1026
threads_enter called from Dummy-1
released mutex
pygtk unblock called from _wrap_gtk_main pid 15831
acquired lock
threads_enter called from MainThread
have gdk lock
threads_leave called from MainThread
MainThread: <Condition(<lock object at 80de9a0>, 0)>.notify(): no waiters
MainThread: <_MainThread(MainThread, stopped)>: exiting
Broken run:
$ python threads.py
in gtk_init()
currentThread(): no current thread for 1026
threads_enter called from Dummy-1
released mutex
acquired lock
threads_enter called from MainThread
------------------------------------------------------
Notice that the difference here is "pygtk unblock called from
_wrap_gtk_main pid 15" in the working run.
James - on the fix for mainiteraion() and eventspending() - I think
the unlock/lock should really go around GTK+ (see Owen's commit to
gtk/gtkmain.c on 07/07/99).
If anyone can replicate this problem on their systems (or point out
our failed logic in setting up mainloop threads. :) - it would be most
helpful.
Thanks a lot.
Matt
[EMAIL PROTECTED]
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
