[Twisted-Python] cReactor fixes

[Brian Warner]

Glyph Lefkowitz <glyph at twistedmatrix.com> writes:
> 
> Ideally, I'd prefer that the reactor is *always* in a consistent state.
> That would probably involve redefining or removing the "crash" facility,
> since there would only be "pause and return so that run() continues" or
> "stop properly so run() restarts". Whatever compromise you come up with in
> this vein is probably acceptable, though.

What do you mean by "consistent"? Let me verify my understanding: we could
say that the two states are running and stopped, and that you can always
transition from one to the other. I'm guessing the reason for .crash and the
prohibition on running .start a second time is the systemEventTriggers, and a
desire to keep them from running more than once in any given process.

If we move to only two states and allow arbitrary transitions between them,
we'd probably have to declare that the triggers run on each transition.
Normal apps won't care, since they only start and stop once. The unit tests
would start/stop 0 or more times per test case, running triggers each time,
but the only triggers in place would probably be the ones added by the tests
themselves.

The other use for .crash listed in the docs is to avoid running shutdown
triggers. I've had programs where the shutdown.tap -writing routine raised an
exception, which appeared to cause the shutdown to abort and the program to
go back to the main loop. I had to kill it with SIGTERM to make it stop. I
imagine .crash could be used in an exception handler that wrapped app.save()
to terminate a program that was having trouble with the "after"-"shutdown"
event triggers. If that is useful, .crash would be just like .stop except it
wouldn't run the triggers.

So:
1: At boot time, we enter the "stopped" state
2: While we are in the "stopped" state, you may only run .start
3: .start moves us from "stopped" to "running" and runs "startup" triggers
4: While we are in the "running" state, you may only run .stop or .crash
5: .stop moves from "running" to "stopped" and runs "shutdown" triggers
6: .crash moves from "running" to "stopped" without running triggers

7: .reset does an implicit .stop, if necessary, before cleaning all reactor
state

All triggers remain attached until individually removed or reactor.reset() is
called, so an app that does .run(); .stop(); .run(); .stop(); is going to
have the triggers run multiple times. All other reactor state is preserved by
.stop and .crash (timers, sockets).


I think I've just restated what you said before, but this way if I got it
wrong somebody has the opportunity to correct my understanding before I get
around to writing any code :)

thanks,
 -Brian