On 12/09/2003 8:42 AM, Tim Evans wrote:
I have created a routine that displays exceptions in a gtk dialog box,
which I place in sys.excepthook. I have run into a problem when using
this routine with threading.
The sys.excepthook function can be run from all sorts of places,
sometimes the gtk lock will be held, other times it won't be. The gdk
thread lock is not guaranteed to be recursive (it's just a GMutex, not
a GStaticRecMutex), so I can't just call gtk.threads_enter every time
as it could deadlock.
Does anyone have a solution to this?
Does anyone else think it would be much easier if the gtk lock was
recursive? GDK_THREADS_ENTER is a macro, so I don't think that the
lock could be changed from a GMutex to a GStaticRecMutex without
breaking binary compatibility.
This is not going to happen. There are many bits of code that use the
GDK_THREADS_ENTER/LEAVE macros, not just in pygtk and GTK proper.
What you can probably do though is to queue an idle handler that
displays the dialog. Next time the main loop is run, your idle handler
will get executed, where you can create and display the dialog. Note
that you will need to put in gtk.threads_enter()/leave() calls in your
idle handler, because the lock isn't held when running an idle.
Alternatively, you could ignore threading completely, and only use your
excepthook with single threaded programs ...
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
