>> Interesstingly, if i run the test with strace, i never see the test
>> fail (i tried at least 30 times):
> This sounds like something Tim had mentioned at one point, where
> tests can fail on a machine that is "too fast"?
Dieter said that. I believe him, but it doesn't match my experience.
Then again, I spend most of my time on Windows boxes, where process
creation is so much slower (than on Linux) that Dieter can't even
imagine that many orders of magnitude <wink>.
Andres Krasa reported that his tests were running on an Intel Xeon 3
GHz Dual-CPU box. Does nobody else here run on a Linux box that fast?
I normally run tests on a 3.4 GHz hyperthreaded box, but it _is_
running WinXP instead, and the spawnve and waitpid implementations on
Windows have nothing in common with their Linux implementations (e.g.,
most Unix signals, including SIGCHLD, don't exist on Windows -- the
OSes have very different ways of managing processes).
> Both with strace and the debugger you "slowed the test down" a bit, and
> they pass. Maybe that's a clue, basically pointing to the fact that the tests
> dodgy rather than the software?
Trying to come up with a small, self-contained test case remains (IMO)
the best way to make progress here. "The tests are dodgy" sounds
appealing until you think about what they do related to the point of
failure: spawn a process, and wait for it to exit later, passing
waitpid() the pid returned by spawnve(). There just isn't anything
complicated (at the Python level) going on there.
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -