[Twisted-Python] why tests are failing with the gtk2 reactor + oldtrial but passing with newtrial
in a nutshell, oldtrial leaves the reactor in a dirty state
in the gtk2 reactor i put in the follwing method:
def printoutallreaders(self): for reader in reads.keys(): print "reader: %r" % reader
in twisted.test.test_internet.InterfaceTestCase.testCallInNextIteration i added the following line (278):
277 reactor.callLater(0, f1) 278 reactor.printoutallreaders()
upon running the test along with the whole suite i got the following output from my method:
testCallInNextIteration ... reader: <twisted.internet.default._UnixWaker instance at 0x404d6b6c> reader: <Echo #0 on ./hello.skt> reader: <twisted.internet.tcp.Client to ('localhost', 50048) at 421a832c> reader: <Echo #0 on echo.skt> reader: <twisted.internet.tcp.Client to ('localhost', 50042) at 421d3b8c> reader: <Echo #0 on 0> reader: <twisted.internet.unix.Client instance at 0x4217836c> reader: <twisted.internet.protocol.ServerFactory on 50046> reader: <twisted.internet.unix.Client instance at 0x421784ac> reader: <Echo #0 on 0> reader: <Echo #0 on 0> reader: <twisted.internet.protocol.Factory on 50051> reader: <Echo #0 on echo.skt> reader: <twisted.protocols.ftp.DTPFactory on 50055> reader: <twisted.internet.protocol.ServerFactory on 50048> reader: <twisted.internet.tcp.Client to ('localhost', 50046) at 421bcaec> reader: <twisted.internet.unix.Client instance at 0x421d39ec>
as you can see, old trial has left a large number of readables in the reactor between tests.
when i run with the same code patched into the retrial-4 branch:
testCallInNextIteration ... reader: <twisted.internet.default._UnixWaker instance at 0x4063c1ec>
you can see that the only readable in the reactor is a _UnixWaker.
so retrial caused this test to work by cleaning up the reactor state, as the test writer expected.
In the end, it was a VERY GOOD THING that JP demanded that I revert the merge of my branch, as the reactor-installation code was flawed.
JP WAS RIGHT I WAS WRONG
let that be a lesson to you all...
it is fixed now in my branch, ans i'm going to test it on pyramid before remerging to make sure there are no further buildbot suprises.
-Jonathan
On Mon, 2004-10-18 at 02:52, Jonathan Simms wrote:
In the end, it was a VERY GOOD THING that JP demanded that I revert the merge of my branch, as the reactor-installation code was flawed.
I am a little confused - the first half of your message makes sense to me, and this makes sense to me, but they do not seem to be connected in any way. How was the reactor-installation code flawed?
Glyph Lefkowitz wrote:
On Mon, 2004-10-18 at 02:52, Jonathan Simms wrote:
In the end, it was a VERY GOOD THING that JP demanded that I revert the merge of my branch, as the reactor-installation code was flawed.
I am a little confused - the first half of your message makes sense to me, and this makes sense to me, but they do not seem to be connected in any way. How was the reactor-installation code flawed?
Heh, well, to be perfectly honest, the only connection between these two things was that it was through debugging one that I discovered the other. Basically, the reactor installation code was flawed because the reactor installation code was somehow factored out, while the option was left in, so no matter what you specified with --reactor, you got the select reactor.
The reason the select reactor was getting installed was that the trial.util class was a top-level import, and it had twisted.internet.reactor as a top-level import.
This is all fixed and tested for now.
-Jonathan
participants (2)
-
Glyph Lefkowitz -
Jonathan Simms