[Twisted-Python] Reactor getting stuck in random places on Windows?

Eric Mangold 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
> reactor.run().
> Any ideas would be appreciated.
> Thanks,
> Steve

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:

In particular:

"(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  
forth evenly.

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,
Eric Mangold
Twisted/Win32 Co-Maintainer

More information about the Twisted-Python mailing list