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

[Andrew McNabb]

On Wed, Nov 05, 2008 at 07:24:31PM -0000, glyph at divmod.com wrote:
>
> 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.

Thanks.  I must have missed the link earlier.


> 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.

I agree that it should be avoided as much as possible, but I don't think
that it should be impossible to do.  Suppose, for example, that you are
refactoring a project to use Twisted.  It's nice to be able to use it
just a little, then iteratively add more to it.  I agree that you
shouldn't stay in this state long, but it sure would be a nice crutch
during refactoring.


> 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.

Give me any API, and I can create a program that misuses it. :)

I'm guessing that the GUI project would be much more decipherable if
instead of having 3 or 4 global reactors, there were 3 or 4 reactors
that were nicely encapsulated.  Anyway, if there's a good reason for
having 3 or 4 reactors, I'm sure there's a good way to organize the code
so that things don't get out of hand.

I think the following use cases for mutliple reactors outweigh the
potential risks:
- starting and stopping a reactor multiple times, particularly for
  testing
- making it easier to refactor existing code to use the reactor pattern
- k threads that each have their own reactor

And I'm sure we could come up with others.


> 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.

If I wanted to be constantly told "you can't do that, it's impossible",
I wouldn't be a Python guy.  If I want to shoot myself in the foot,
that's my problem.  :)


-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://twistedmatrix.com/pipermail/twisted-web/attachments/20081105/02eac900/attachment.pgp