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/

Reply via email to