[Twisted-Python] "disconnecting properly" in tests still hangs on macOS

[exvito here]

> On 14 Nov 2018, at 08:50, Chris Withers <chris at withers.org> wrote:
> 
> 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?


Chris,

I played with this for a bit and quickly reproduced the "server side disconnect never seems to happen" behaviour you described, on my system running macOS 10.12.6 and Twisted 18.9.0 using the SelectReactor.

Suspecting of an eventual race condition between "server stop listen" and "server disconnect", I tried this variation of tearDown which seems to work reliably:

    @defer.inlineCallbacks
    def tearDown(self):
        self.clientConnection.disconnect()
        yield defer.gatherResults([self.clientDisconnected, self.serverDisconnected])
        yield defer.maybeDeferred(self.serverPort.stopListening)

Do I have any motive to suspect such race condition? No, but after ensuring "disconnect first, stop listening later", things work much better here.

Also tested the CFReactor and KQueueReactor: CFReactor seems to exhibit a similar behaviour (original code hangs every now and then on cleanup, my code works); KQueueReactor always hangs on cleanup with the original code, and works reliably with my code.

My 2c.,
--
exvito