On Feb 26, 2010, at 12:26 AM, K. Richard Pixley wrote:
> Is it a reasonable workaround, or are there any nonobvious downsides to using
> reactor.waker.connectionLost(None) either...
Yes. Lots. This is an _extremely_ hazardous area of Twisted to be mucking
around with, as it may appear to work until it completely locks up your process.
> a) immediately after instantiating my reactor, (assuming I don't need a
> waker), or...
You always need a waker. Twisted uses threads internally for several things:
the two that come to mind immediately are name resolution and signal handling.
If you remove the waker, you will get hangs and crashes.
> b) immediately before or after calling reactor.stop
You need to wait for the reactor to fully shut down (i.e. 'run' exits, not
'stop' has been called) since service cleanup may be asynchronous and need to
do things like resolve DNS names and handle further signals during shutdown
(especially SIGCHLD, as subprocesses will typically exit during shutdown).
> I guess I'm asking why that hasn't been included in reactor.stop already.
The implementation is tricky, and you have to audit all the internal state that
the reactor keeps. To make matters worse, the test coverage for this area of
Twisted is worse than others, because it's old code that works well enough and
therefore (A) was written before Twisted had strong quality requirements such
as complete test coverage, and (B) since it works well enough, it hasn't been
extensively modified and therefore hasn't had to be re-examined to improve its
test coverage to 100%.
But please, contribute patches to fix it! It isn't *that* hard, mostly it's
just that we've had lots of other stuff to do. (See the weekly emails from
trac about how many open tickets there are!)
_______________________________________________
Twisted-Python mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
