7 ms·

This project sounds too good to be true. I would be quite astonished if they can make fork() work seamlessly without an amazingly high performance cost. In my e

This project sounds too good to be true. I would be quite astonished if they can make fork() work seamlessly without an amazingly high performance cost. In my experience the only way to do such a thing is to use NtCreateProcess(), but that function itself seems impossible for anyone besides Microsoft to use correctly. (I have tried numerous times and failed, and so have many others.)

TickleSteve 11y ago
[https://www.cygwin.com/faq.html#faq.api.fork https://www.cygwin.com/faq.html#faq.api.fork] 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.
- wfunction 11y ago
  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.
  - TickleSteve 11y ago
    I've personally never had any real performance issues with Cygwin. What are you doing that involves lots of forking? For me, Cygwin has always been pretty much native-speed, its only an API translation layer.
    - wfunction 11y ago
      > What are you doing that involves lots of forking? Running scripts? Also, try enumerating the files in a large directory hierarchy and compare it with native Windows speed (or Linux speed), it's not even comparable.
      - TickleSteve 11y ago
        fair enough, it probably wont match native for that. Personally tho, speed has always been sufficient for me to never notice. I use it most days, but I don't do comparisons.
        wfunction 11y ago
        "Won't match native" is quite the understatement. It's not a question of a 40% speed difference, more like a > 400% speed difference last time I checked.
    - gnoway 11y ago
      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.
    - 11y ago
- e12e 11y ago
  After reading that, the idea behind colinux[1] doesn't seem quite as crazy. Doesn't look like it's been ported to 64bit, though :( [1] http://www.colinux.org/ http://www.colinux.org/
userbinator 11y ago
This is part of the reason why I don't think compatibility layers like this are worth bothering with if you're after performance - different OSs do things in different ways, and while it's possible to make one work like another, it's sub-optimal because that wasn't the use-case the OS was designed for. It's really a high-level design decision: Applications originally designed for *nix will use fork(), while those for Windows will use something else - maybe threads, maybe CreateProcess().
- pjmlp 11y ago
  Not only that, like Mac OS X, Windows is moving into another application model WinRT with containers. Just like Carbon, only selected Win32 APIs will survive in the long run. Which leaves the question how much POSIX can be implemented on top of WinRT. Similarly not all POSIX calls are allowed inside Mac OS X App Sandbox. And if we restrain ourselves to POSIX there is little more than command line applications, TCP/IP headless servers and Motif GUIs.
  - netheril96 11y ago
    > Which leaves the question how much POSIX can be implemented on top of WinRT. > Similarly not all POSIX calls are allowed inside Mac OS X App Sandbox. Except that WinRT as well as OS X Sandboxed App are all unpopular and therefore unlikely to replace the regular apps anywhere near in the future.
    - pjmlp 11y ago
      If you prefer another set of examples, iOS, Android, Arduino, HTML 5. For me POSIX is a kind of unofficial C runtime. Now with systems moving beyond C, POSIX matters much less.
  - cwyers 11y ago
    > Not only that, like Mac OS X, Windows is moving into another application model WinRT with containers. Just like Carbon, only selected Win32 APIs will survive in the long run. Microsoft would still let you run 16-bit DOS apps on Windows if Intel hadn't dropped compatibility from their 64-bit processors. Both of us will be dead and buried before Win32 goes away.

TickleSteve 11y ago

[https://www.cygwin.com/faq.html#faq.api.fork https://www.cygwin.com/faq.html#faq.api.fork] 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.

wfunction 11y ago
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.
- TickleSteve 11y ago
  I've personally never had any real performance issues with Cygwin. What are you doing that involves lots of forking? For me, Cygwin has always been pretty much native-speed, its only an API translation layer.
  - wfunction 11y ago
    > What are you doing that involves lots of forking? Running scripts? Also, try enumerating the files in a large directory hierarchy and compare it with native Windows speed (or Linux speed), it's not even comparable.
    - TickleSteve 11y ago
      fair enough, it probably wont match native for that. Personally tho, speed has always been sufficient for me to never notice. I use it most days, but I don't do comparisons.
      - wfunction 11y ago
        "Won't match native" is quite the understatement. It's not a question of a 40% speed difference, more like a > 400% speed difference last time I checked.
  - gnoway 11y ago
    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.
  - 11y ago
e12e 11y ago
After reading that, the idea behind colinux[1] doesn't seem quite as crazy. Doesn't look like it's been ported to 64bit, though :( [1] http://www.colinux.org/ http://www.colinux.org/

userbinator 11y ago

This is part of the reason why I don't think compatibility layers like this are worth bothering with if you're after performance - different OSs do things in different ways, and while it's possible to make one work like another, it's sub-optimal because that wasn't the use-case the OS was designed for. It's really a high-level design decision: Applications originally designed for *nix will use fork(), while those for Windows will use something else - maybe threads, maybe CreateProcess().

pjmlp 11y ago
Not only that, like Mac OS X, Windows is moving into another application model WinRT with containers. Just like Carbon, only selected Win32 APIs will survive in the long run. Which leaves the question how much POSIX can be implemented on top of WinRT. Similarly not all POSIX calls are allowed inside Mac OS X App Sandbox. And if we restrain ourselves to POSIX there is little more than command line applications, TCP/IP headless servers and Motif GUIs.
- netheril96 11y ago
  > Which leaves the question how much POSIX can be implemented on top of WinRT. > Similarly not all POSIX calls are allowed inside Mac OS X App Sandbox. Except that WinRT as well as OS X Sandboxed App are all unpopular and therefore unlikely to replace the regular apps anywhere near in the future.
  - pjmlp 11y ago
    If you prefer another set of examples, iOS, Android, Arduino, HTML 5. For me POSIX is a kind of unofficial C runtime. Now with systems moving beyond C, POSIX matters much less.
- cwyers 11y ago
  > Not only that, like Mac OS X, Windows is moving into another application model WinRT with containers. Just like Carbon, only selected Win32 APIs will survive in the long run. Microsoft would still let you run 16-bit DOS apps on Windows if Intel hadn't dropped compatibility from their 64-bit processors. Both of us will be dead and buried before Win32 goes away.