On Mar 13, 2012, at 10:44 PM, Itamar Turner-Trauring wrote:
twisted.internet.test.reactormixins says: CFReactor uses APIs which manipulate global state, so it's not safe to run its own reactor-builder tests under itself.
We also don't have a buildslave running under cfreactor. Which means it's currently completely untested. I filed a ticket to fix that - https://bugs.launchpad.net/twisted-buildbot-configuration/+bug/954680
Not completely untested. If you search a recent OS X build log, for example <http://buildbot.twistedmatrix.com/builders/osx10.6-py2.6-select/builds/1952/...>, you will see lots of "_CFReactor" tests that pass. Ironically a builder run under CFReactor itself will test less code related to the CFReactor, because it will only run the haphazard tests that test the global reactor by returning Deferreds rather than running the reactor. But it does test different stuff, so there's value in having it run both ways.
That still leaves the problem with global state though. Since we want to move towards having tests create new reactors, that's problematic. What global state does it manipulate, and what can we do about it?
It manipulates the CoreFoundation run loop for its thread. Ironically, the reason that this is the case is that CF's API, much like Twisted itself, is not reentrant. If you're interested, <http://developer.apple.com/library/mac/#documentation/CoreFoundation/Referen...> is a pretty comprehensive reference. We can't really do anything about it unless we can make Twisted start a new thread for each reactorbuilder test and then destroy the thread at the end. Or, unless we mock the whole CF API - which, honestly, isn't that hard, there aren't a ton of functions and they do pretty straightforward stuff. -glyph