Introduction

On Windows, Python multiprocessing uses the spawn start method instead of fork, which means each child process starts a fresh interpreter and imports your module again. That is why code that seems fine on Linux can fail on Windows with a RuntimeError unless process-creation code is protected correctly.

Why Windows Behaves Differently

Unix-like systems often use fork, which duplicates the current process state. Windows does not support fork in the same way, so Python starts a new interpreter and re-imports the main module.

If top-level code immediately starts more child processes during that import, you get recursive process creation and the familiar runtime error.

The Required Fix: Guard the Entry Point

The standard fix is to place process-creation code under the main-guard block.

1from multiprocessing import Process
2
3
4def worker():
5    print("child process running")
6
7
8if __name__ == "__main__":
9    p = Process(target=worker)
10    p.start()
11    p.join()

On Windows, this is not optional style. It is required for correct multiprocessing behavior in normal scripts.

What Not to Do

This pattern is unsafe on Windows:

1from multiprocessing import Process
2
3
4def worker():
5    print("child process running")
6
7p = Process(target=worker)
8p.start()
9p.join()

Because process creation happens at import time, child interpreters re-import the module and run the same code again. That triggers the failure.

freeze_support Can Matter Too

If the program may be packaged into an executable with tools such as PyInstaller, adding freeze_support is a good habit.

1from multiprocessing import Process, freeze_support
2
3
4def worker():
5    print("child process running")
6
7
8if __name__ == "__main__":
9    freeze_support()
10    p = Process(target=worker)
11    p.start()
12    p.join()

It is not always necessary in plain script execution, but it becomes important in frozen application scenarios.

Pools Follow the Same Rule

The same entry-point rule applies to Pool and higher-level multiprocessing helpers.

1from multiprocessing import Pool
2
3
4def square(x):
5    return x * x
6
7
8if __name__ == "__main__":
9    with Pool(4) as pool:
10        print(pool.map(square, [1, 2, 3, 4]))

If you forget the guard, the problem is the same: top-level process startup code runs when child processes import the module.

Jupyter and Interactive Environments Add Complexity

Interactive notebooks and REPL environments can make multiprocessing harder because there may be no normal importable script entry point.

In those cases, common strategies include:

• moving multiprocessing code into a real .py module
• using thread-based concurrency if the workload allows it
• using joblib or another higher-level tool that fits the environment better

The core rule is still the same: child processes need an import-safe entry point.

A Good Mental Model

On Windows, write multiprocessing code as if the module will be imported again by each child process, because that is effectively what happens.

That mental model makes several best practices obvious:

• keep side effects out of top-level module code
• put process startup inside if __name__ == "__main__":
• keep worker functions importable
• avoid relying on interpreter state that exists only in the parent process

Common Pitfalls

The most common mistake is creating processes at module import time instead of inside the main guard.

Another common issue is testing only on Linux or macOS and then discovering the problem later on Windows. Developers also often define worker functions or process setup in ways that are awkward for the spawn model, which makes the code harder to import correctly in child processes.

Summary

• Windows multiprocessing uses spawn, not fork.
• Child processes import the main module again, so import-time process creation breaks.
• Put process startup under if __name__ == "__main__":.
• Use freeze_support() when packaging into executables may be involved.
• Write multiprocessing code so it remains safe when the module is imported by child processes.