[Twisted-Python] threadedselectreactor and twistd

Stefano Masini stefano at pragma2000.com
Tue Sep 13 11:39:11 EDT 2005

On 9/12/05, Antony Kummel <antonykummel at yahoo.com> wrote:
> Not sure what you mean.
> If threadedselectreactor can't integrate with twistd,
> then the problem that threadedselectreactor solves is
> inherent to twistd, in which case twistd is simply
> unsuitable for some uses (i.e. GUI)?


using twisted with GUIs is not trivial, and I found it quite tricky.
But in the end it's possible and in fact I do it all the time. Here's
the best solution I could find so far, using wxPython:

1) Run wxPython in the main thread
2) Run twisted reactor in a secondary thread
3) Have special proxy objects that bridge calls from gui code (running
in one thread) and network code (running inside another)

It doesn't sound nice, but it's not as bad as it seems.

The problem is that there's not much you can do about it, really:
first of all, wxPython is made in such a way that if you don't use its
own event loop, you won't be able to use modal dialogs (which simply
sucks). So you can't really use wxreactor, and similar solutions if
you want to build anything more complex that hello world.

Conversely, you can't use wxPython's event loop to process twisted
events because it's not responsive enough. So you're left with the
multiple threads solution only.

Once you have this, you need to deal with the communication problem:
say your network code is dealing with a protocol that fails, and you
want to warn the used with an error dialog. You can't really call
wx.ErrorDialog(...).ShowModal() because your code is running in the
wrong thread, so you have to wx.CallAfter(myShowDialogMethod, ...).

Similarly, if the user clicks on the "Connect" button, you can't call
twisted code from within the OnClick() event handler because you're
again in the wrong thread. Therefore you have to
reactor.callFromThread(myBeginConnectionMethod, ...).

So, dealing with these wx.CallAfter and reactor.callFromThread quickly
urges you to write proxies whose methods are decorated in such a way
that just by calling them from one thread triggers their execution in
the other thread.

When I discovered all these issues, I searched for code online and
found something that I can't find again, but looks a lot like this
(and could very well be the same):

I wrote this in a bit of a rush, I hope I was clear enough.
If this is relevant to you, let me know in case you need more info.


More information about the Twisted-Python mailing list