`sys.argv` no longer correct during main module execution using `forkserver`

[tpwrules]

Bug report

Bug description:

The following code, invoked with python3 ~/test.py foo:

import multiprocessing
import sys

print("args in module", sys.argv[1:])

def fun():
    print("args in fun", sys.argv[1:])

if __name__ == "__main__":
    multiprocessing.set_start_method("forkserver")

    fun()

    p = multiprocessing.Process(target=fun)
    p.start()
    p.join()

prints the following results on Python 3.12, 3.13.4, and 3.14.0b3:

args in module ['foo']
args in fun ['foo']
args in module ['foo']
args in fun ['foo']

but on Python 3.13.11 and 3.14.2 prints the following results:

args in module ['foo']
args in fun ['foo']
args in module []
args in fun ['foo']

For whatever reason, these latter versions change forkserver to set up sys.argv after the main module is imported, instead of before. As far as I can tell, the former results are always printed using spawn; that always sets up sys.argv before the main module is imported.

If the code depends on sys.argv in the main module, then the subprocess does not do the same thing as the main process and bad things can happen.

This change tripped me up when fixing a program for the new forkserver default. It's unclear if it's a bug, because I admit our program is naughty about running code in a module like this, but this may be something to fix and at least may serve as documentation of a pitfall for others even if there is nothing to change.

CPython versions tested on:

3.12, 3.13, 3.14

Operating systems tested on:

Linux

[a12k]

Looks like sys.argv isn't being set before importing the main module in forkserver's main function. I would say the fix is likely in Lib/multiprocessing/forkserver.py. Maybe this is a regression caused by gh-126631, but don't know without deeper investigation. I'd be happy to investigate further and submit a PR. I don't think the fix would be all that complex.

[picnixz]

@gpshead Was it an intended change?