Question

From what I understand about twisted, nothing running in the reactor thread should block. All blocking activities should be delegated to other threads, to fire callbacks back into the reactor thread when they’re done.

So does this apply to gtk things as well? For example, I want to display a “connection failed” message if the connection… failed. Do I do:

def connectionFailed(self, reason):
    dlg = gtk.MessageDialog(type=gtk.MESSAGE_ERROR,
                      buttons=gtk.BUTTONS_CLOSE,
                      message_format="Could not connect to server:\n%s" % (
                          reason.getErrorMessage()))
    dlg.run()

or:

def connectionFailed(self, reason):
    dlg = gtk.MessageDialog(type=gtk.MESSAGE_ERROR,
                      buttons=gtk.BUTTONS_CLOSE,
                      message_format="Could not connect to server:\n%s" % (
                          reason.getErrorMessage()))
    reactor.callInThread(dlg.run)

or:

def connectionFailed(self, reason):
    def bloogedy():
        dlg = gtk.MessageDialog(type=gtk.MESSAGE_ERROR,
                          buttons=gtk.BUTTONS_CLOSE,
                          message_format="Could not connect to server:\n%s" % (
                              reason.getErrorMessage()))
        dlg.run()
    reactor.callInThread(bloogedy)

?

EDIT: Ooh ok, the latter two really messed up. so I guess the answer is the first. Then my question is: why? It seems like this would block the reactor thread.

Answer 1

Your problem doesn’t actually have anything to do with threads and GUIs. You should always use Twisted and GTK from the same thread: there’s no need to do otherwise.

Your problem is that you are using gtk.Dialog.run(). This is an API that you should never use, Twisted or not. It runs a re-entrant main loop, which causes your current event handler to block, but allowing other event handlers to execute one layer down the stack. GTK has excellent support for re-entrant main loops, but Twisted doesn’t (and that’s okay because like I said, you shouldn’t use them).

MessageDialog.run won’t work in a thread, anyway, so you don’t actually have that option. It will cause unpredictable behavior which can cause your application to behave weirdly or crash. GTK has fine support for threads, but there are things that you are just never supposed to do with a thread because it doesn’t make any sense, and this is one of them.

If you’re dealing with code that isn’t doing any processing, but just wants to wait for something to happen (like waiting for a user to press a button on a dialog) you should use functions which return Deferreds, not threads. As it so happens, gtk.Dialogs will emit a signal at the point where they are responded to: “response“. You can use this to wire up a very simple function that displays your message with a dialog and returns a Deferred when it’s complete. Here’s an example:

def showMessage(text):
    mdlg = gtk.MessageDialog(type=gtk.MESSAGE_INFO,
                             buttons=gtk.BUTTONS_CLOSE,
                             message_format=text)
    result = Deferred()
    def response(dialog, response_id):
        mdlg.destroy()
        result.callback(response_id)
        return False
    mdlg.connect("response", response)
    mdlg.show_all()
    return result