RE: Deadlock problem
- From: "David Moffatt" <David Moffatt access-company com>
- To: <gtk-list gnome org>
- Subject: RE: Deadlock problem
- Date: Wed, 19 Aug 2009 10:27:47 -0700
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
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.
From: gtk-list-bounces gnome org [mailto:gtk-list-bounces gnome org] On
Behalf Of gtk-list-request gnome org
Sent: Wednesday, August 19, 2009 5:00 AM
To: gtk-list gnome org
Subject: gtk-list Digest, Vol 64, Issue 21
Send gtk-list mailing list submissions to
gtk-list gnome org
To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
gtk-list-request gnome org
You can reach the person managing the list at
gtk-list-owner gnome org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of gtk-list digest..."
1. Re: Deadlock problem when calling messagebox function with
idle_add (Andreas Sommer)
Date: Wed, 19 Aug 2009 00:02:39 +0100
From: Andreas Sommer <AndiDog web de>
Subject: Re: Deadlock problem when calling messagebox function with
To: Robert Pearce <rob bdt-home demon co uk>
Cc: gtk-list gnome org
Message-ID: <4A8B330F 5050406 web de>
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
>> 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...
gtk-list mailing list
gtk-list gnome org
End of gtk-list Digest, Vol 64, Issue 21
] [Thread Prev