[Twisted-Python] Re-entrancy policy for the reactor
Itamar Turner-Trauring
itamar at itamarst.org
Sun Jul 24 22:51:08 EDT 2011
I'm going to merge #5063 next time I have a few minutes when I'm more
awake, which will mean my yak stack[1] is empty and I can go back to
working on abortConnection(). As explained in
http://twistedmatrix.com/trac/ticket/78, abortConnection() is like
loseConnection(), except it doesn't wait until buffers are written out,
it closes the connection immediately. The question is, how immediately?
My current implementation, a bit like one of the half-close code paths,
ends up calling connectionLost directly. That means you can have a call
stack that looks like this:
MyProtocol.dataReceived
TCPConnection.abortConnection
...
MyProtocol.connectionLost
This can lead to re-entrancy bugs. I am tempted to suggest a policy of
No Reactor Reentrancy, but that is currently violated by one of the TCP
half-close code paths, and producers if I'm not mistaken.
Some options:
(a) Leave abortConnection() reentrant.
(b) Make abortConnection() non-reentrant, don't change any current APIs.
(c) Make all reactor APIs non-reentrant.
(Since there's a ticket for documenting the reentrancy policy, you will
notice I've added another yak to my stack. I'll finish #78 someday!)
Thoughts?
References:
[1] https://secure.wikimedia.org/wiktionary/en/wiki/yak_shaving
More information about the Twisted-Python
mailing list