RE: Deadlock problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux