It did silently break something: __main__ can no longer be pre-loaded.

import multiprocessing
import os

print(f"importing {__name__} ({__file__}) pid={os.getpid()}")

def runner():
    print(f"running in {os.getpid()}")

if __name__ == '__main__':
    multiprocessing.set_start_method('forkserver')
    multiprocessing.set_forkserver_preload(['__main__'])

    N=4
    procs = [multiprocessing.Process(target=runner) for _ in range(N)]
    for p in procs:
        p.start()
    for p in procs:
        p.join()

Currently:

importing __main__ (/home/duaneg/src/cpython/data/126631/repro.py) pid=946571
importing __mp_main__ (/home/duaneg/src/cpython/data/126631/repro.py) pid=946574
running in 946574
importing __mp_main__ (/home/duaneg/src/cpython/data/126631/repro.py) pid=946575
running in 946575
importing __mp_main__ (/home/duaneg/src/cpython/data/126631/repro.py) pid=946576
running in 946576
importing __mp_main__ (/home/duaneg/src/cpython/data/126631/repro.py) pid=946577
running in 946577

If we fix it (and presumably before 3.4, although I haven't tested):

importing __main__ (/home/duaneg/src/cpython/data/126631/repro.py) pid=946458
importing __mp_main__ (/home/duaneg/src/cpython/data/126631/repro.py) pid=946460
running in 946461
running in 946462
running in 946463
running in 946464

Having said that, no-one noticing for eleven years suggests it isn't actually required. Perhaps it would be better to simplify things and remove the code? I'll post a quick and dirty fix, for reference.

FWIW one place where __main__ preloading is explicitly used "to speed up tests" are the fork server tests themselves. The fixed version does indeed use a little less CPU (a quick & crude check shows ~2% improvement), however the actual elapsed time is not significantly affected as these tests spend most of their time waiting and sleeping.

In fact, the fork server's default preload list is ['__main__'], so this bug affects all uses of fork server that don't explicitly set preload to not include __main__. Given that, I am more inclined to think we should fix this: CPU/energy savings may be small for each individual use, but will quickly add up across all fork server use globally. However, it also raises the risk, as it will affect all multiprocessing users who don't override the default settings.

In trying to reshape the repro script into a regression test, I ran into some truly bizarre behaviour: it was working when run directly but produced spurious output when run as a unit test, even with the exact same command line and environment! It turns out the fork server is not flushing stdout before forking, so if any of the modules it preloads writes to a buffered stdout/stderr but doesn't flush, it will be inherited by the child process(es). This is partially masked by this bug, since it is most likely to be an issue for the __main__ module. I'll open a separate issue for this.