[Twisted-Python] at what point does reactor.run() need to be called?

[Bob Ippolito]

On Apr 6, 2004, at 6:01 AM, Michal Pasternak wrote:

> Damon Fasching [Mon, Apr 05, 2004 at 11:39:57PM -0700]:
>> The following two modules work fine together.
>
> reactor.run() enters an event-controlled loop (it's the same as 
> "mainloop"
> in GUI toolkits you could program in), so you should call it after you 
> do
> all initialization stuff.
>
>> However, if the call to reactor.run() is moved any
>> higher in client.py, the client seems to hang.  For
>
> It doesn't hang, it just gets the root object, but has no callback to 
> pass
> it to.
>
> If it hangs (locks-up hard), it's a bug, examine & report it.

I wouldn't say that "locks-up hard" in this particular scenario (the 
reactor isn't supposed to be doing anything) is always a bug -- at 
least in the case of an alternative reactor implementation.  If you 
send a signal (such as SIGINT or ctrl-C) to the program, and Python 
swallows it (as it normally would), the not-written-in-Python event 
loop won't know that it would be a good idea to run some Python code, 
so it will never quit.  If you really want to guarantee that your 
program is indeed interruptible you should add a little "waker" that 
runs Python code (even if it's little more than "pass") every few 
seconds via callLater.

This was an issue until very recently with cfreactor.  However, I have 
written a new signal handler (in PyObjC CVS) that is installed by 
default (when you use AppHelper.run[Console]EventLoop) that uses a mach 
port to wake the not-written-in-Python event loop and runs some Python 
code immediately.  So it's no longer a problem when you are using 
PyObjC to start your event loop in the recommended way, or you install 
the mach port signal handler manually (it registers to the 
CoreFoundation runLoop, which cfreactor uses if you do not specify one 
to reactor.run or you do not have an NSApplication instance created).

-bob