[Tim] > Since nobody has made real progress on figuring out why test_fork1 > fails on some systems, would somebody who is able to make it fail > please just try this patch & see what happens? [Charles G Waldman] > Or try this program (based on Neil's example), which will fail almost > immediately unless you apply my patch: Not "or", please, "both". Without understanding the problem in detail, we have no idea how many bugs are lurking here. For example, Python allocates at least two locks besides "the global lock", and "doing something" about the latter alone may not help with all the failing test cases. Note too that the pthread_atfork docs were discussed earlier, and neither Guido nor I were able to dream up a scenario that accounted for the details of most failures people *saw*: we both stumbled into another (and the same) failing scenario, but it didn't match the stacktraces people posted (which showed deadlocks/hangs in the *parent* thread; but at a fork, only the state of the locks in the child "can" get screwed up). The patch you posted should plug the "deadlock in the child" scenario we did understand, but that scenario didn't appear to be relevant in most cases. The more info the better, let's just be careful to test *everything* that failed before writing this off.
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