Re: Deadlock problem when calling messagebox function with idle_add



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]