[Thomas Wouters]
I have also seen test_fork1 failures on BSDI, using a SMP machine, but I haven't tried it on non-SMP (we don't have too many of those). However, all our BSDI kernels are the same, having been built for SMP. Meetings permitting (which is doubtful, today :-() I'll see if I can pin that down.
It would, however, be fairly peculiar if test_fork1 breaks on all SMP-supporting systems... I don't really recall a reason for thread semantics to change reliably based on kernel/cpu settings, and it would be silly for them to do so! But I'll admit threads are silly, period ;-)
Silly? Without threads your clothes would fall off <wink>. I wonder whether the "fork" part is a red herring here. It's extremely rare to see a thread bug that actually requires a multi-headed machine to trigger (in fact, I don't believe I've ever seen one), but the nature of races in flawed threaded code is often such that you're a million times more *likely* to hit a bad timing window on a multi-headed machine than on a time-sliced single-headed box. And this is particularly true under operating systems that are reluctant to switch threads on a singled-headed box. For example, 1.5.2's dreaded invalid_tstate bug had never been reported on a single-headed box until I spent several *hours* hand-crafting an extreme test case to provoke it on one (and that was after I was sure I had located the timing hole "by thought", so knew exactly what I needed to do to trigger it -- 'twas very hard to provoke it on a one-headed box even then!).
6-AM-and-preparing-for-a-full-10-hour-day-of-meetings-:-S-ly y'rs,
So long as you still put in your 18 hours on Python today, we're happy to let you engage in all the recreational activities you like <wink>. generously y'rs - tim