[Twisted-web] Having reactor run at the main thread make things harder for late adopters

glyph at divmod.com glyph at divmod.com
Wed Nov 5 14:24:31 EST 2008


On 03:08 pm, amcnabb at mcnabbs.org wrote:
>On Wed, Nov 05, 2008 at 03:11:08PM +1100, Andrew Bennetts wrote:
>>
>>The documentation could perhaps be clearer about this (that document 
>>implies,
>>but doesn't directly state, that there's only one reactor instance).
>
>I've always struggled with reactor being a singleton.  It makes it very
>difficult to use Twisted on a small scale in a larger existing project.
>Sometimes it would be really nice to stop a reactor and later start
>another one.  Unit testing is one of several situations where this can
>be a problem.
>
>I suppose this wouldn't be quite as severe of a problem if it were easy
>to restart a stopped reactor, but even then, it would be nice to be 
>able
>to have two threads that each have their own reactor.  But I guess I'm
>just ranting now. :)

I completely agree, architecturally speaking, for Twisted, that this is 
a good idea.  I already linked to 
<http://twistedmatrix.com/trac/ticket/3205> in this thread, which is a 
broad outline of my long-term plan to eliminate the reactor's singleton- 
ness.

On the other hand, the approach you're describing here, using Twisted 
"just a little", starting up a reactor and spinning it in some obscure 
corner of an application, is basically an architectural antipattern, 
which should be avoided as much as possible.  One of the hardest things 
to do on a modern software project is to keep a coherent high-level 
system design that makes enough sense to introduce new people to it. 
Concurrency, in particular, is a property which is basically impossible 
to introduce into a software system without a comprehensive rethinking 
of how the whole thing works.

I can definitely think of a few "larger projects" - names withheld to 
protect the guilty - whose designs have been influenced and 
rehabilitated by their decision to use Twisted.  I worry about making it 
easier to throw Twisted into a situation where it will make the overall 
design of a system into even more of an incomprehensible mess.  Just 
imagine trying to decipher a GUI project using Twisted for networking, 
where there are 3 or 4 different global reactors, each of which is used 
by a different window or dialog box, and you have to figure out which 
one you need based on what context your Twisted-using code is running 
in.

It's nice to be able to say "you can't do that, it's impossible", when 
someone asks how to set up something like that.



More information about the Twisted-web mailing list