Bob Ippolito wrote:
I don't know what the deal is, exactly, because it uses python sockets internally and that works perfectly fine. I believe that something about the waker causes the run loop to think that it's always awake. I didn't feel like looking too far into it. That said, Apple's implementation of CFRunLoop does everything that the reactor does (and then some), including thread waking and other thread communication facilities.. so when I have more time I'll look into the cause and the appropriate solution. IIRC the only part of Twisted that uses threads on its own is the DB stuff, anything else would probably be implemented using more native means (nobody uses cfreactor for cross-platform applications yet), so I don't see an immediate problem with ignoring the waker. I'd rather punish threaded (from what Twisted sees) applications than make all applications really really slow and resource hungry.
If there are better thread communication facilities in the CFRunLoop, then make your reactor's call[From/In]Thread use them. There's nothing intrinsically useful about the waker; it's an implementation detail of callFromThread which could be better done in another way. However, "really slow" doesn't quite describe the problem. A server which sends an event to a thread without a waker and then receives a callFromThread may never wake up, if there isn't more network activity happening.