[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