A generator copied into fork workers repeats its whole stream once per worker
If a loader puts a Python generator into process-pool workers (initargs, a global, or a framework's 'shared sequences') and each task calls next() on it, every forked worker advances its own copy. If the generator shuffles with the global np.random, the copies shuffle identically and training receives each item N times (N = workers). CPython 3.12.16 / NumPy 2.5.4, fork Pool(4), 16 next() calls on an endless shuffled stream of 32 ids: 4 distinct ids, each repeated 4 times. With np.random.seed() in the initializer: 12 distinct, max 2 repeats. That is right for independent sampling (about 12.7 expected), but the workers still don't split the data between them. Under spawn and forkserver the setup fails up front (TypeError: cannot pickle 'generator' object), so this only bites on fork. Detect it by logging item ids in the parent and looking for runs or counts equal to the worker count. Fix: use an index-based dataset (the parent hands out indices), not a shared generator.
Scope of the fix line: index-based delivery stops the data duplication. In my runs a Sequence-style iterator with 4 fork workers and the indices handed out by the parent covered 64/64 samples. It does NOT stop the duplicated random draws inside the workers: augmentation params were still identical across workers (3 distinct of 24 batches). You still need per-worker RNG streams for that, and if the permutation is drawn lazily in the workers, draw it in the parent first.
Confirmed through a real framework path: standalone Keras GeneratorEnqueuer(use_multiprocessing=True), which is what fit_generator uses for a plain generator. It stores the generator in _SHARED_SEQUENCES and hands it to an mp.Pool. Linux fork, Python 3.8 / NumPy 1.18.5, 4 workers, a shuffle-per-epoch generator over 20 ids: Keras 2.3.1 gave 5 and 6 distinct ids in the first 20 batches (two runs); in the first run every id came in a run of 4. Keras 2.2.4 and 2.2.5 behaved the same. Keras 2.2.2 gave 13 of 20, and no batch repeated with identical random content. Up to 2.2.2 the parent called np.random.seed(None) before forking each worker; from 2.2.3 init_pool_generator reseeds only if a random_seed is passed, and fit_generator never passes one. So the version matters as much as the start method. A cheap fix that keeps the generator: create rng = np.random.default_rng() as the first line of the generator body, which first runs inside the worker. With that, 40 of 40 values were distinct (13 of 40 with global np.random).