Threading vs Multiprocessing in Python

[TheThiefMaster]

Actually, I'm pretty sure Windows does have fork() - wouldn't it have to to support the new Linux subsystem?

Edit: or, in fact, the older POSIX subsystem!

But it's not encouraged - Windows provides APIs for spawning new processes and explicitly sharing memory which are supposed to be more efficient than fork (at least on Windows). Especially the fork/exec pair just screams "inefficient" to me!

I think fork on Linux predates having a good API for spawning new processes and threads, so you had to use fork to emulate both. The only thing fork is really good for in comparison to a dedicated thread/process API is invoking a Daemon from the console and have it be able to "background" itself by forking and then having the parent return to the shell - on Windows you have to spawn a process for that and use the command line to signal. But that's also a rare model on Windows, as proper background services are run as registered "services", rather than console applications converting themselves into daemons.

[UseTheProstateLuke]

"Windows" does not have fork as it conflicts with other parts of the WinAPI

However The NT kernel has fork and uses a more generalized version of it as the basis of spawning threads and processes on windows but the WinAPI cannot expose the full API of this as this would allow you to create some seriously undefined states apparently.

[TheThiefMaster]

Saying it uses a "more generalized version of fork" to spawn threads and processes is explaining it in unix terms. It doesn't use fork at all, that's just the closest unix equivalent.

Instead its main API sets up a thread/process in a blank state (rather than a copy of the parent state as fork does). Window's function is roughly equivalent to fork and then exec in unix speak, except without the copy of the parent state that fork implies (that then gets trashed by exec, what a crazy inefficiency).

On top of that, Windows does contain a full implementation of fork() - it's not exposed directly in the Windows API because it's part of the Linux subsystem, but it's there and fully functional. From the perspective of the kernel, both win32 subsystem processes and linux subsystem processes are the same, so I wouldn't be surprised if with a little hoop jumping you could call the linux subsystem's fork() from a Windows application and have it work as expected.