[Thomas Wouters]
... And anyway, I thought the test_fork1 test tested for fork() behaviour in threads. It spawns a thread,
Four threads, actually.
fork()s one of those threads,
It forks "the main" thread, which is in addition to the four it spawns.
and tests to see if the other threads still exist after the fork(), in the new child. The entire test is done in Python code, so how the scheduler and/or race conditions come into play isn't too obvious to me. Except of course the whole test if flawed.
The test uses loops and time.sleep instead of proper synchronization, so its behavior is at best probabilistic, depending entirely on timing accidents (*likely* accidents, but accidents all the same). But I don't have a machine here that supports fork at all, so I can't run it, and I don't know how it fails on the machines it fails on. If it's failing with a thread exiting with a non-zero exit code, then I'd say the timing uncertainties in the *Python* code are irrelevant, and it's the failing platform's fork implementation that's broken.