[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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4