> * "-j1" would explicitly turn off multiprocessing Running tests "sequentially" but run them in one subprocess per test file is interesting for tests isolation. Runing tests one by one reduces the risk of triggering a race condition (test only failing when the system load is high). -jN was always documented as "use multiprocessing". Maybe we need a new option to explicitly disable multiprocessing instead? vstinner at apu$ ./python -m test Run tests sequentially vs vstinner at apu$ ./python -m test -j1 Run tests in parallel using 1 child processes By the way, Python 2.7 behaves differently and it's annoying: vstinner at apu$ ./python -m test -j0 Run tests sequentially I'm in favor of modifying Python 2.7 to detect the number of cores for -j0, as Python 3.6 does, and run tests in parallel. Python 3.6: vstinner at apu$ ./python -m test -j0 Run tests in parallel using 10 child processes About the default: run tests in parallel or -j1 are the two most reliable options. While -j0 is faster, sometimes it triggers race conditions. I'm not sure that it's safe to change that, at least maybe don't do that in stable branches but only master? Note: Obviously, I'm strongly in favor of fixing all race conditions. I'm doing that for years. We are better today, but we are still not race-condition-free yet. Victor
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