RE: Deadlock problem

["David Moffatt" <David Moffatt access-company com>]

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 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
	http://mail.gnome.org/mailman/listinfo/gtk-list
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..."


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 web de>
Subject: Re: Deadlock problem when calling messagebox function with
	idle_add
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
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 gnome org
http://mail.gnome.org/mailman/listinfo/gtk-list


End of gtk-list Digest, Vol 64, Issue 21
****************************************