Re: Deadlock problem when calling messagebox function with idle_add
- From: Robert Pearce <rob bdt-home demon co uk>
- To: gtk-list gnome org
- Subject: Re: Deadlock problem when calling messagebox function with idle_add
- Date: Tue, 18 Aug 2009 18:50:09 +0100
On Tue, 18 Aug 2009 17:18:25 +0100 Andreas wrote:
> Okay I found a workaround:
>
Please try not to top-post. Replies to posts, even your own, should quote the relevant bits only and THEN respond to them. I've shuffled things below:
> Andreas Sommer wrote:
> >
> > I have a function /putMessageBox/ which shows a message box dialog
> > like this (it's Python but I think it's not specific to that language):
> >
> > ...
> > dialog.run()
> > dialog.hide()
> > ...
> >
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.
> > Calling the function normally from somewhere in the main thread works,
> > but when I execute it with
> >
> > def helper():
> > putMessageBox(...)
> > gobject.idle_add(helper)
> >
> > it deadlocks as soon as I press the OK button on the dialog.
You appear to be showing the dialog whenever the GTK loop is idle. This seems a very unlikely requirement for a modal dialog.
>> The
> > dialog does not disappear, the buttons stays pressed and the complete
> > application is stuck. Same with timeout_add, of course.
That may not be a strictly accurate assessment. What happens, I suspect, is that the dialog is shown and handled, but when the user clicks "OK" and closes it, the main loop drops back to the idle state and immediately re-runs the dialog.
Later you wrote:
> Okay I found a workaround:
>
> def helper():
> *gtk.gdk.threads_enter()*
> putMessageBox(...)
> * gtk.gdk.threads_leave()*
> gobject.idle_add(helper)
>
> But why do I have to do that? Note that I call the above from the main
> thread, no multithreading involved. Please can somebody explain why this
> is necessary?
>
There is some threading involved, of sorts. The dialog.run call creates a new GTK mainloop purely for that dialog. It's possible that the threads_enter is preventing the dialog's main loop from running the idle tasks that would otherwise re-run the dialog when you don't want it.
I think we will need to see much more of the structure of your application to be able to help further.
HTH
Rob
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]