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!)