[Twisted-Python] Re: [Twisted-commits] r11107 - Delete fundamentally broken test.

[James Y Knight]

Sigh I probably ought to have read the process_pausing.py script, too. 
:) I was wrongly assuming it was just doing something nice and simple. 
Anyhow, I can see how it could easily cause spurious failures, as it's 
depending on the process scheduling doing *just* what it wants, which 
is obviously unreliable.

That it hangs is still a bad thing, since even if the timing is wrong, 
it oughtn't be hanging.
...
But I have traced down the problem:
"if len(self.data) != 5: raise ValueError"
Apparently, the exception raised from inside processEnded just gets 
eaten somewhere instead of raised back through to the test framework. 
Thus, if the test takes more than 9.999 seconds to complete, it will 
raise an exception and not set self.elapsed. Then, the test will sit in 
the reactor.iterate loop forever waiting for self.elapsed to be set.

Okay, I'm satisfied the error was completely in the test. However, it 
does now seem that pauseProducing isn't tested at all.

James

On Jul 23, 2004, at 10:07 AM, Andrew Bennetts wrote:

> On Fri, Jul 23, 2004 at 09:38:56AM -0400, James Y Knight wrote:
>> Wait, wait, that causes *hangs*? That seems like a bad thing. It
>> doesn't look like an obviously wrong thing to do to me. Do you know
>> *why* it's hanging?
>
> I'm not sure why it's hanging, and I'd be happy for someone to figure 
> out
> why.  Ideally they'd fix the problem too, if there is one.
>
> My suspicion is that the bug is in that test, not in Twisted, though.  
> The
> process_pausing.py script itself is far too ugly to have any 
> confidence in.
> It tries to detect that writes to stdout block by looking at times, 
> which is
> extremely fragile.  Worse, detecting that writing to stdout blocks 
> doesn't
> necessarily prove anything anyway: the intention (presumably, the test 
> has
> no comments) is apparently to test that pauseProducing on a transport 
> will
> cause pipes from a child process to be unread and hence let the buffers
> fill.  But the child process could just as easily be finding that the 
> writes
> are blocking because it's simply writing more frequently than the 
> parent is
> reading, e.g. due to scheduling anomalies...
>
> I'm also not aware of any real world reports of problems with the 
> process
> code hanging, despite the test being pretty prone to intermittent 
> failure,
> which is also highly suggestive that the test is broken, not the code.
>
> I also have difficulty imagining a scenario which would rely upon this
> behaviour.  The OS is free to buffer writes to pipes as much as it 
> wants,
> even if the other end is unread, so this isn't something that can be
> portably relied on to give any useful information.  If the parent 
> really
> wants to signal to the child that it should behave differently, then 
> ought
> to tell that to the child directly, either via a message down a pipe, 
> or a
> signal, or some other channel.  Relying upon indirect side-effects 
> doesn't
> strike me as a good practice.
>
> In short: the test's intention is undocumented, and appears to be 
> testing
> something fundamentally unuseful, and is contributing zero additional
> confidence in the code base by being in the test suite, but is 
> contributing
> a considerable amount of noise on the buildbot due to failures that 
> are more
> than likely spurious.  We're better off without it.
>
> -Andrew.
>
>
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>