[Python-Dev] test_fork1 on SMP?

[Tim Peters]

[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