On Jun 18, 2005, at 2:58 PM, Jp Calderone wrote:
> This changes dataReceived to call down into user code while the
> LineReceiver's instance attributes are in an inconsistent state.
> This can lead to duplicate data delivery if dataReceived is called
> into from lineReceived. Normally this sounds like a ridiculous
> thing to do, but notice the implementation of resumeProducing():
>> def resumeProducing(self):
> self.paused = False
> self.dataReceived('')
> self.transport.resumeProducing()
>> Since resumeProducing is called immediately when a producer is
> registered, this means LineReceivers can no longer register
> themselves as producers for their transports from lineReceived,
> which is a much more reasonable thing to do.
>> Demonstration of the bug in action attached.
Two things about that:
1) resumeProducing actually now says:
def resumeProducing(self):
self.paused = False
self.transport.resumeProducing()
self.dataReceived('')
This was changed because of <http://twistedmatrix.com/pipermail/
twisted-python/2005-February/009626.html> also <http://
twistedmatrix.com/bugs/issue899>.
However, if resumeProducing is allowed to immediately produce data,
this is somewhat bogus, as it could reverse the order of the data. In
reality, a TCP transport's resumeProducing will not immediately
produce data, but I think that's a fragile API to both have
resumeProducing immediately produce data, and depend on a call to
someone else resumeProducing not immediately producing data. I think
there's an issue here.
2) dataReceived can be easily fixed to handle this by using a local
-- patch coming separately.
James