[Twisted-Python] Re: [Twisted-commits] r11107 - Delete fundamentally broken test.
andrew-twisted at puzzling.org
Fri Jul 23 10:07:23 EDT 2004
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.
More information about the Twisted-Python