GNOME Bugzilla – Bug 606796
Calling Dialog's run() in a signal handler is blocking other threads from using GTK
Last modified: 2012-09-02 12:59:30 UTC
Created attachment 151297 [details] Copy of the thread dump (relevant part) When Dialog's run() is called from a signal hanlder other threads are blocked. It is not possible to use GTK or to make any another action. Threads appear to be BLOCKED. Using Window's present() can a workaround.
Raised on the java-gnome-hackers mailing list so we can have a discussiona about it. As we discussed on IRC, a workaround is to not use Dialog's run() and instead call Window's present() and then connect() to Dialog.Response. That way you won't be calling a nested main loops in a signal handler, but rather will just let the Dialog do it's think in the existing main thread. If you can do those tests we discussed over the weekend to confirm the entry/leave behaviour, that'd really help. Is the nesting in fact > 1 when your other thread is being blocked? AfC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
This shouldn't have been closed, so re-openning. Maybe, Fabio, we could ask you to not close bugs opened by developers? if someone says NEEDINFO to another hacker it's because they need input. Thanks! AfC
We now have a patch that inform people that they should not use the run() method but use the workaround instead. I think that it's still need a fix because well it's still a ugly bug. Maybe we could try to fix that after the API break.
It appears Slashtime ran afoul of this when I ported it to use Application; switching to an idle callback appears to allow the AboutDialog to work without blocking the main loop. AfC