FYI, I saw a similar problem. It was not quite the same thing but if I launched my dialog from the idle handler it would deadlock the main loop after it exited. When I launched the same dialog from a menu item it worked perfectly. I could stop this behavior by removing the thread initialization calls. (The threads themselves were commented out too). I never solved it I just rewrote my app to remove threading and pulled the g_thread_init(), gdk_threads_init() out. -----Original Message----- From: gtk-list-bounces@xxxxxxxxx [mailto:gtk-list-bounces@xxxxxxxxx] On Behalf Of gtk-list-request@xxxxxxxxx Sent: Wednesday, August 19, 2009 5:00 AM To: gtk-list@xxxxxxxxx Subject: gtk-list Digest, Vol 64, Issue 21 Send gtk-list mailing list submissions to gtk-list@xxxxxxxxx To subscribe or unsubscribe via the World Wide Web, visit http://mail.gnome.org/mailman/listinfo/gtk-list or, via email, send a message with subject or body 'help' to gtk-list-request@xxxxxxxxx You can reach the person managing the list at gtk-list-owner@xxxxxxxxx When replying, please edit your Subject line so it is more specific than "Re: Contents of gtk-list digest..." Today's Topics: 1. Re: Deadlock problem when calling messagebox function with idle_add (Andreas Sommer) ---------------------------------------------------------------------- Message: 1 Date: Wed, 19 Aug 2009 00:02:39 +0100 From: Andreas Sommer <AndiDog@xxxxxx> Subject: Re: Deadlock problem when calling messagebox function with idle_add To: Robert Pearce <rob@xxxxxxxxxxxxxxxxxxxx> Cc: gtk-list@xxxxxxxxx Message-ID: <4A8B330F.5050406@xxxxxx> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Robert Pearce wrote: > That function is fine if you want to execute the dialog as a "modal" dialog, i.e. the other windows block until it's been acknowledged. If you want the dialog non-modal (i.e. works in parallel with other windows) you should use a different approach. > I want the message box to be modal, that's fine. > You appear to be showing the dialog whenever the GTK loop is idle. This seems a very unlikely requirement for a modal dialog. > Sorry that you misunderstood my code... in Python, /None/ is returned by default which means the idle function only runs once (like returning FALSE in a GTK written in C). So it's /not/ a problem with re-running the dialog all the time. >> The dialog does not disappear, the buttons stays pressed and the complete >> application is stuck. Same with timeout_add, of course. >> To be more accurate: As soon as I press the OK button, the button stays pressed. I'm 99% sure that its signal handler deadlocks because GTK signal handlers call gtk.gdk.threads_enter theirselves (according to the FAQ). I think that this OK button signal handler and something in the top-level window's main loop both try to call gtk.gdk.threads_enter which then leads to the deadlock. Doing my workaround (= threads_enter surrounding the dialog run) will let any other threads_enter calls from the top-level window's main loop block. Does that make any sense?! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.gnome.org/archives/gtk-list/attachments/20090819/d855e9ef/a ttachment.html> ------------------------------ _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list End of gtk-list Digest, Vol 64, Issue 21 **************************************** _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
