Re: Deadlock problem when calling messagebox function with idle_add

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?!

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