What is the closest thing windows has to fork()?

Question

I guess the question says it all.

I want to fork on windows. What is the most similar operation and how do I use it.

Answer 1

Well, windows doesn't really have anything quite like it. Especially since fork can be used to conceptually create a thread or a process in *nix.

So, I'd have to say:

CreateProcess()/CreateProcessEx()

and

CreateThread() (I've heard that for C applications, _beginthreadex() is better).

Answer 2

Your best options are CreateProcess() or CreateThread(). There is more information on porting here.

Answer 3

There is no easy way to emulate fork() on Windows.

I suggest you to use threads instead.

Answer 4

The following document provides some information on porting code from UNIX to Win32: http://msdn.microsoft.com/en-us/library/y23kc048(vs.71).aspx

Among other things, it indicates that the process model is quite different between the two systems and recommends consideration of CreateProcess and CreateThread where fork()-like behavior is required.

Answer 5

CreateProcess() is the closest thing Windows has to fork() but Windows requires you to specify an executable to run in that process.

The UNIX process creation is quite different. It basically duplicates the current process almost in total, each in their own address space and starts running them separately.

The real equivalent of CreateProcess() is the fork()/exec() pair of UNIX. It's not necessary for the exec() to happen since the process itself may have different code paths for parent and child.

If you're porting software to Windows and you don't mind a translation layer, Cygwin may provide the capability that you want (I've never had the need to test fork() under Cygwin so I can't say for sure).

Answer 6

Cygwin has fully featured fork() on Windows. Thus if using Cygwin is acceptable for you, then the problem is solved in the case performance is not an issue.

Otherwise you can take a look at how Cygwin implements fork(). From a quite old Cygwin's architecture doc:

5.6. Process Creation The fork call in Cygwin is particularly interesting because it does not map well on top of the Win32 API. This makes it very difficult to implement correctly. Currently, the Cygwin fork is a non-copy-on-write implementation similar to what was present in early flavors of UNIX.

The first thing that happens when a parent process forks a child process is that the parent initializes a space in the Cygwin process table for the child. It then creates a suspended child process using the Win32 CreateProcess call. Next, the parent process calls setjmp to save its own context and sets a pointer to this in a Cygwin shared memory area (shared among all Cygwin tasks). It then fills in the child's .data and .bss sections by copying from its own address space into the suspended child's address space. After the child's address space is initialized, the child is run while the parent waits on a mutex. The child discovers it has been forked and longjumps using the saved jump buffer. The child then sets the mutex the parent is waiting on and blocks on another mutex. This is the signal for the parent to copy its stack and heap into the child, after which it releases the mutex the child is waiting on and returns from the fork call. Finally, the child wakes from blocking on the last mutex, recreates any memory-mapped areas passed to it via the shared area, and returns from fork itself.

While we have some ideas as to how to speed up our fork implementation by reducing the number of context switches between the parent and child process, fork will almost certainly always be inefficient under Win32. Fortunately, in most circumstances the spawn family of calls provided by Cygwin can be substituted for a fork/exec pair with only a little effort. These calls map cleanly on top of the Win32 API. As a result, they are much more efficient. Changing the compiler's driver program to call spawn instead of fork was a trivial change and increased compilation speeds by twenty to thirty percent in our tests.

However, spawn and exec present their own set of difficulties. Because there is no way to do an actual exec under Win32, Cygwin has to invent its own Process IDs (PIDs). As a result, when a process performs multiple exec calls, there will be multiple Windows PIDs associated with a single Cygwin PID. In some cases, stubs of each of these Win32 processes may linger, waiting for their exec'd Cygwin process to exit.

Sounds like a lot of work, doesn't it? And yes, it is slooooow.

EDIT: the doc is slightly outdated. The current implementation is somewhat different, thanks to this excellent answer for the reference.

Answer 7

I certainly don't know the details on this because I've never done it it, but the native NT API has a capability to fork a process (the POSIX subsystem on Windows needs this capability - I'm not sure if the POSIX subsystem is even supported anymore).

A search for ZwCreateProcess() should get you some more details - for example this:

• http://groups.google.com/group/comp.os.ms-windows.programmer.nt.kernel-mode/browse_thread/thread/86837f458b67a79f/eeceb4c546b35314

Though note that Corinna Vinschen indicates that Cygwin found this unreliable:

• http://www.eggheadcafe.com/conversation.aspx?messageid=32086952&threadid=32040421