Right, so, I've been trying to get the technique in
https://jml.io/pages/how-to-disconnect-in-twisted-really.html to work
for me.
No hating please, most of my testing in the past has involved hitting a
relational database, so there's already a TCP connection flying around,
one more won't make any difference.
jml's example, exactly as-is on that page, hangs around 30-40% of the
time when running on my macOS laptop. From changing the teardown to look
like this:
def tearDown(self):
ds = defer.maybeDeferred(self.serverPort.stopListening)
dc = defer.maybeDeferred(self.clientConnection.disconnect)
print()
ds.addCallback(lambda _: print('serverPort.stopListening'))
dc.addCallback(lambda _: print('self.clientConnection.disconnect'))
self.clientDisconnected.addCallback(lambda _:
print('self.clientDisconnected'))
self.serverDisconnected.addCallback(lambda _:
print('self.serverDisconnected'))
self.serverDisconnected.addErrback(lambda _:
print('self.serverDisconnected:', _))
return defer.gatherResults([ds, dc, self.clientDisconnected,
self.serverDisconnected])
...it appears that it's the serverDisconnected deferred that's failing
to fire. I can't reproduce this on Linux as of yet, so I'm guessing this
is a difference between the SelectReactor used on macOS and the
EPollReactor used on Linux.
What's the best way to go about debugging a non-firing deferred like this?
Anyone know what this might be?
cheers,
Chris
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
