[Twisted-Python] Reactor getting stuck in random places on Windows?
teratorn at twistedmatrix.com
Sat Feb 3 10:10:14 EST 2007
On Fri, 02 Feb 2007 23:13:36 -0600, Steve Freitas <sflist at ihonk.com> wrote:
> I'm writing a Twisted client that uses PB. It seems to be getting stuck
> intermittently -- failing to respond to the server's queries. Sometimes
> it gets stuck immediately after login, sometimes after it's been running
> fine for a while. I'm starting the Twisted client in a terminal window.
> What unsticks it in these cases is always a single ^C. Now, sometimes
> that spits up an unhandled exception from some place into the log
> (stdout) and then it goes on its merry way -- other times it has no
> error to report and moves on like nothing happened.
> I'm frequently ctrl-C'ing this program as I try my new changes, and
> sometimes it takes one to kill it, and sometimes it takes two. Hopefully
> this is a clue.
> I thought perhaps I had a deferred that was hanging, but in the entire
> client, I'm calling addCallback() exactly once -- and it's followed by
> an addErrback(), so I don't think the problem is there.
> I first noticed this behavior when it was running as a Windows service,
> and I thought it may have been related to the necessity of starting the
> reactor with calling reactor.run(installSignalHandlers=0) (I didn't yet
> see the tip about periodically passing child signals to the reactor),
> but it still happens, albeit apparently less often, with a simple
> Any ideas would be appreciated.
Well I don't really know what your problem is, but here are some things
you can think about and see if any little lights go off in your head :)
Are you running sub-processes? If a sub-process shares the same console
some interesting things can happen.
There isn't any way to tell which process will receive console input. See
this page for what Microsoft has to say about it:
"(By default, a console process inherits its parent's console, and there
is no guarantee that input is received by the process for which it was
Indeed, you can verify this by running a parent process and a child
process that both read bytes from stdin. You will see that the bytes are
sent to one process or the other. In my testing it alternated back and
Other forms of console input, such as ^C, seem to go to both processes at
the same time. At least that is what happened in my simple test.
Maybe for you it's only delivering the ^C to one of the procsses, and
sometimes it's the right one and sometimes not?
Or maybe it's much simpler than this and you just have a bare "except:"
that is catching and hiding the first KeyboardInterrupt?
As for why your process is hanging in the first place, who is to say?
Maybe try running under WingIDE (or something) and break in w/ the
debugger when things hang up. The stack trace ought to give you some clues.
Hope that helps,
More information about the Twisted-Python