Parent initializes a space in the Cygwin process table for child. Parent creates child suspended using Win32 CreateProcess call, giving the same path it was invoked with itself. Parent calls setjmp to save its own context and then sets a pointer to this in the Cygwin shared memory area (shared among all Cygwin tasks). Parent fills in the child's .data and .bss subsections by copying from its own address space into the suspended child's address space. Parent then starts the child. Parent waits on mutex for child to get to safe point. Child starts and discovers if has been forked and then longjumps using the saved jump buffer. Child sets mutex parent is waiting on and then blocks on another mutex waiting for parent to fill in its stack and heap. Parent notices child is in safe area, copies stack and heap from itself into child, releases the mutex the child is waiting on and returns from the fork call. Child wakes from blocking on mutex, recreates any mmapped areas passed to it via shared area and then returns from fork itself.
And where is the copy-on-write happening here? If I recall correctly, the problem was that attempting to reproduce fork()'s copy-on-write behavior on Windows resulted in a massive performance hit. (Which, IIRC, contributes to the slowness of Cygwin.)
EDIT: Oh, I'd skipped the part above "here's how it works"... that just says exactly the same thing I said above.
It is possibly to fork on Windows by using ZwCreateProcess directly, however the win32 subsystem and every single thirdparty library you are using does not expect this. If you are only using the NT native api then it should work just fine, but you are prevented from interacting with the win32 environment.
> if you are only using the NT native API then it should work just fine
I believe I had trouble executing any instructions in the new process at all. If you can make it work I'd like to see your code, otherwise I'm skeptical.
AFAIK this is how fork() is implemented in SUA, but I haven't tried it myself. You could load the SUA subsystem dll into IDA Pro and see how they actually do it.
I believe the POSIX subsystem has some kind of support from the native API that prevents you from writing your own random subsystem and expecting it to work; I don't remember what it was though (it's been a few years).
There's some special handling when loading the image where it does different things depending on the value of the subsystem field, but I don't know whether there's any special handling in the kernel that can't be duplicated by using the native api. But the NT kernel does very little when it comes to initializing new processes, most of the initialization is done in user space by ntdll, so it seems unlikely.
> had problems with getting it to work with the win32 subsystem
Keep in mind that the whole _point_ of Cygwin is to interact with the Windows world. If you want a POSIX sandbox, you can use a VM with fewer headaches and better performance.
Keep in mind that in addition to the build steps, it's common to break out to sed, grep, and shell to get basic string operations done due to extremely limited capability of make itself. On cygwin, this is slow for large projects.
I have few "real" performance issues with Cygwin as well. However, when I perform the same tasks in gnu/linux there is a noticeable speed increase. So what I mean to say is that Cygwin's performance isn't necessarily bad, it's just not as good as the real thing.
I use Cygwin as my terminal environment for everything that works. Any fs operation involving lots of files (e.g. find) is slow. Copying files is slow. CIFS in particular seems much slower via //server/share in Cygwin than native \\server\share.
One way to really see the latter is to try to create a git clone using the --reference option against a repo on a mapped drive; msysgit using the drive letter is OK, but cygwin git against the same repo via /cygdrive/mapped is very slow.
Edit: by 'everything that works' I mean everything that interacts with the terminal in a standard way. There are some command line utilities which output to the terminal some way other than stdout, making them very difficult to use in cygwin.
Here's how it works:
Parent initializes a space in the Cygwin process table for child. Parent creates child suspended using Win32 CreateProcess call, giving the same path it was invoked with itself. Parent calls setjmp to save its own context and then sets a pointer to this in the Cygwin shared memory area (shared among all Cygwin tasks). Parent fills in the child's .data and .bss subsections by copying from its own address space into the suspended child's address space. Parent then starts the child. Parent waits on mutex for child to get to safe point. Child starts and discovers if has been forked and then longjumps using the saved jump buffer. Child sets mutex parent is waiting on and then blocks on another mutex waiting for parent to fill in its stack and heap. Parent notices child is in safe area, copies stack and heap from itself into child, releases the mutex the child is waiting on and returns from the fork call. Child wakes from blocking on mutex, recreates any mmapped areas passed to it via shared area and then returns from fork itself.