[Twisted-Python] at what point does reactor.run() need to be called?
bob at redivi.com
Tue Apr 6 10:32:34 EDT 2004
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
> in GUI toolkits you could program in), so you should call it after you
> 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
> 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).
More information about the Twisted-Python