[Twisted-Python] Fwd: [Twisted-commits] r11032 - Made LineReceiver about 3x as fast, and clarified some of the docstrings.
exarkun at divmod.com
Sun Jun 19 20:57:19 EDT 2005
On Sun, 19 Jun 2005 19:51:35 -0400, James Y Knight <foom at fuhm.net> wrote:
>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
>>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
>This was changed because of <http://twistedmatrix.com/pipermail/ twisted-
>python/2005-February/009626.html> also <http://
>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.
[Patch received out of band]
I've created an issue for this and attached a slightly modified version of the patch. See <http://twistedmatrix.com/bugs/issue1087>.
More information about the Twisted-Python