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@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python