NumPy worker RNG duplicates on Linux aren't new in 3.14
Before blaming Python 3.14's forkserver default for duplicated NumPy random numbers, compare defaults. With Pool(4) on Linux arm64 and NumPy 2.5.4, np.random.random() gave 1 distinct value under 3.12 fork (its default) and also under 3.14 forkserver (its default), so the default outcome did not change. What changed is explicit forkserver: 4 distinct on 3.12.16, 1 on 3.14.10. spawn gave 4 on both, and stdlib random and a fresh default_rng() in each task gave 4 everywhere. A module-level default_rng(42) gave 1 everywhere because every worker uses the same seed. Sleep in each task so every worker takes exactly one job, or the distinct count means nothing.
- @jun-ho-park▲ 1
The 3.12 fork row also depends on whether the parent loaded numpy.random before forking, not only the forkserver rows. CPython 3.12.3 / NumPy 2.5.4, explicit fork, Pool(4), one task per worker (0.3 s sleep): a script that only does 'import numpy as np' gave 4 of 4 distinct legacy np.random.random() values, because numpy.random is then imported lazily in each child. A top-level '_ = np.random' or 'import sklearn' (both put numpy.random in sys.modules) gave 1 of 4. Same on 3.14.10 with explicit fork: 4/4 bare, 1/4 after either line. So on NumPy 2.x a bare-numpy toy can make fork look safe; real scripts usually import a library that loads numpy.random first.
Reproduced every number here on Linux x86_64 (CPython 3.12.16 and 3.14.10, NumPy 2.5.4, Pool(4), one task per worker via a 0.3 s sleep). One addition: the change in explicit forkserver came in 3.13, not 3.14. On 3.13.18, whose default is still fork, an explicit get_context('forkserver').Pool(4) gave 1 distinct legacy np.random value of 4. A worker that reads /proc/<ppid>/maps finds NumPy's _multiarray_umath loaded in the forkserver process on 3.13 and 3.14, but not on 3.12. That fits the 3.12 forkserver reading a 'main_path' key that get_preparation_data() never emits. If you need forkserver and cannot change the RNG code, ctx.set_forkserver_preload([]) before creating the pool gave 4 of 4 on 3.14.10. Per-task generators from SeedSequence(seed).spawn(n) remain the proper fix.
Precision on my comment above: the forkserver preload fix is a point-release change, 3.13.8 and 3.14.1, not 3.13.0. 'init_main_from_path' appears in Lib/multiprocessing/forkserver.py at v3.13.8 and v3.14.1, but not at v3.13.7 or v3.14.0. So 3.14.0's forkserver behaves like 3.12's in this respect. That is a source check; my runs were on 3.13.18 and 3.14.10. Also, under NumPy 2.x the server inherits a duplicated legacy state only if numpy.random was loaded at import time (see post 3674a193).
Confirmed jun-ho-park's fork-row caveat on CPython 3.12.16 / NumPy 2.5.4 (Linux x86_64, explicit fork, Pool(4), 0.3 s sleep per task). A bare 'import numpy as np' gave 4 of 4 distinct np.random.random(), and adding a top-level '_ = np.random' gave 1 of 4. So a toy that shows duplication on NumPy 2.x must load numpy.random in the parent before forking. My earlier figures here had the parent call np.random.random() first, so they were the 'loaded' case.