[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 21:55:37 EST 2008


On 5 Nov, 09:19 pm, amcnabb at mcnabbs.org wrote:
>On Wed, Nov 05, 2008 at 07:24:31PM -0000, glyph at divmod.com wrote:

>>On the other hand, the approach you're describing here, using Twisted
>>"just a little", ... 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.

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

Oh, come on.  This is a totally bogus argument, and I suspect you 
already know that :).  First of all, it's not true: in some languages (E 
comes to mind) it is possible to create APIs which are literally not 
abusable (for some suitable definition of "abuse", this one about global 
state included).

It's the thing Perl people say when you corner them and make a strong 
case that Python is objectively more readable than Perl.  "Sure, but you 
can create an unreadable program in any language".  That's not the 
point; the point is, does tool X make it more *likely* that you'll 
create maintainable programs?  Does X help people learn how to create 
maintainable programs?  Twisted should be doing those things.
>I think the following use cases for mutliple reactors outweigh the
>potential risks:

This is almost certainly true, and as I've already said I am keenly 
interested in de-globalizing the reactor myself; making it easier to 
test things is a key reason for doing so.  However, we should be aware 
of the risks and try to mitigate them.  It could well be that we could 
come up with an API which is smooth as glass for the "good" use-cases we 
have in mind here, and raises exceptions or emits helpful warnings when 
used for the "bad" ones.  Maybe that's not possible, maybe we can only 
get halfway there: but it would be nice to try.

In fact, it would be a much better influence on architecture to have 
intentional, helpful error messages rather than buggy, non-deterministic 
and unsupported behavior.
>- k threads that each have their own reactor

This is a whole other, almost unrelated can of worms.  You can only use 
Twisted from one thread at a time.  There are things which make 
assumptions about non-reentrancy and mutual exclusion of global module- 
level state.  You can find and fix every instance of this if you want, 
but don't bundle it in with multiple reactors :).
>>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.  :)

Another bogus argument.  There are lots of things that are "impossible" 
in Python.  For example, you "can't" change the values of a tuple, or 
the contents of a string.  I mean, there's terrible stuff you can do 
with ctypes, but if it breaks, you get to keep both pieces.  Similarly, 
there are lots of things that already kind of work, by accident, if you 
instantiate multiple reactors; you can kind of re-set a reactor if you 
know exactly what to twiddle.

When I say it's nice to be able to say that something's impossible, that 
doesn't mean that I don't want to support all the reasonable use-cases, 
just that boundaries are a useful tool.  This is very much the Python 
idiom - consider your options for indenting your code in strange ways, 
for example :).



More information about the Twisted-web mailing list