4 ms·

Okay, this one has me laughing out loud. Of COURSE Microsoft doesn't like fork()... Windows pretty much can't do it. I'll admit, there have been a lot of time

Okay, this one has me laughing out loud. Of COURSE Microsoft doesn't like fork()... Windows pretty much can't do it. I'll admit, there have been a lot of times I wish there was a more streamlined way to spawn processes on Linux (particularly daemons) but when I don't have fork() I always end up missing it. I'd take this paper a lot more seriously if it came from someone with a less obvious bias.

jchw 7y ago
Well, couldn't. Whatever they're doing with LXSS and picoprocesses seems to be good enough. I don't run Windows so I'm far from the most biased person but frankly, on the surface the fork/exec thing really does seem unnecessary and weird in the modern world, where we've come up with better ways to do concurrency than just raw threads and processes anyways.
CalChris 7y ago
ONE of the authors is from Microsoft. The other THREE are at Boston University and ETH.
wyldfire 7y ago
The article pointed out legitimate drawbacks related to the intersection of fork() and other features like posix threads. The paper mentions the benefit of posix_spawn for the fork+exec use case. I might've seen posix_spawn while skimming a manpage or browsing a change log but this is the first time that I'd actually learned about its purpose. The article's conclusion isn't "and therefore Linux is bad" btw.
swiley 7y ago
I thought Linux had clone which glibc called for their implementation of fork.
- eesmith 7y ago
  Section 6: REPLACING FORK > Alternative: clone(). > This syscall underlies all process and thread creation on Linux. Like Plan 9’s rfork() which preceded it, it takes separate flags controlling the child’s kernel state: address space, file descriptor table, namespaces, etc. This avoids one problem of fork: that its behaviour is implicit or undefined for many abstractions. However, for each resource there are two options: either share the resource between parent and child, or else copy it. As a result, clone suffers most of the same problems as fork (§4–5).
- zenexer 7y ago
  Yes, the underlying syscall for fork() is clone [1], and the underlying syscall for exec*() is execve [2]. [1]: http://man7.org/linux/man-pages/man2/fork.2.html#NOTES http://man7.org/linux/man-pages/man2/fork.2.html#NOTES [2]: http://man7.org/linux/man-pages/man2/execve.2.html http://man7.org/linux/man-pages/man2/execve.2.html
DannyBee 7y ago
As the article points out, the NT kernel actually natively supports fork. It's just not exposed.
arghwhat 7y ago
As Linux developer and Windows hater, I agree with Microsoft. fork() is a hack. Of course, all Windows APIs are terrible, but that doesn't make complaints about fork() any less legitimate. The concept of Establishing empty processes, instead of cloning yourself, is much more sane. After all, the use of fork() is 99% of the time just to call execve(), and anything done in between is just to clean up the mess from fork(). Having a dedicated way to just create processes in a controlled fashion would have been better there. And, the other 1% is usually cases where pthread should have been used instead.
- gmueckl 7y ago
  Cleaning up your own process between fork and exec is hard. Several programs resort to terrible hacks like force-closing everything except file IDs 0,1,2 in a loop. Or they look into their /proc directory to discover whichnfile IDs exist, which is only marginally better. But when your process is a house of cards built on third party libraries with their own minds, there are not a lot of other options.
  - tobias3 7y ago
    Use O_CLOEXEC everywhere (even third party libs). It's really annoying, but necessary. Means you need to use accept4(), dup3(), popen with an additional "e" (of course all of that needs to be feature tested, during compilation/runtime).
    - cryptonector 7y ago
      Win32 has the opposite semantics, that O_CLOEXEC is the default semantics and the app has to request the opposite if it wants it, and this causes problems too. There should have been two flags and the application should have to specify one on every handle-/fd-creating system call. Hindsight is 20/20.
    - gmueckl 7y ago
      The catch is that you may not be able to control 3rd party libraries enough to be be able to do all that. Thus all these annoying hacks. To me, the complexity of using fork() and the race conditions around pid reuse are the worst design problems of POSIX systems.
magicalhippo 7y ago
Which part of the paper made you laugh out loud? Their arguments of why fork() is not a good fit these days seemed pretty reasonable to me.
zvrba 7y ago
> Windows pretty much can't do it. Win32 API cannot do it. The underlying NT kernel can.
cryptonector 7y ago
I've been working with Unix systems for a long time. I too dislike fork(), even though I used to think it was the greatest thing. Here's a write-up of mine as to fork() being "evil": https://gist.github.com/nicowilliams/a8a07b0fc75df05f684c23c18d7db234 https://gist.github.com/nicowilliams/a8a07b0fc75df05f684c23c...

jchw 7y ago

Well, couldn't. Whatever they're doing with LXSS and picoprocesses seems to be good enough. I don't run Windows so I'm far from the most biased person but frankly, on the surface the fork/exec thing really does seem unnecessary and weird in the modern world, where we've come up with better ways to do concurrency than just raw threads and processes anyways.

CalChris 7y ago

ONE of the authors is from Microsoft. The other THREE are at Boston University and ETH.

wyldfire 7y ago

The article pointed out legitimate drawbacks related to the intersection of fork() and other features like posix threads. The paper mentions the benefit of posix_spawn for the fork+exec use case. I might've seen posix_spawn while skimming a manpage or browsing a change log but this is the first time that I'd actually learned about its purpose. The article's conclusion isn't "and therefore Linux is bad" btw.

swiley 7y ago

I thought Linux had clone which glibc called for their implementation of fork.

eesmith 7y ago
Section 6: REPLACING FORK > Alternative: clone(). > This syscall underlies all process and thread creation on Linux. Like Plan 9’s rfork() which preceded it, it takes separate flags controlling the child’s kernel state: address space, file descriptor table, namespaces, etc. This avoids one problem of fork: that its behaviour is implicit or undefined for many abstractions. However, for each resource there are two options: either share the resource between parent and child, or else copy it. As a result, clone suffers most of the same problems as fork (§4–5).
zenexer 7y ago
Yes, the underlying syscall for fork() is clone [1], and the underlying syscall for exec*() is execve [2]. [1]: http://man7.org/linux/man-pages/man2/fork.2.html#NOTES http://man7.org/linux/man-pages/man2/fork.2.html#NOTES [2]: http://man7.org/linux/man-pages/man2/execve.2.html http://man7.org/linux/man-pages/man2/execve.2.html

DannyBee 7y ago

As the article points out, the NT kernel actually natively supports fork. It's just not exposed.

arghwhat 7y ago

As Linux developer and Windows hater, I agree with Microsoft. fork() is a hack. Of course, all Windows APIs are terrible, but that doesn't make complaints about fork() any less legitimate. The concept of Establishing empty processes, instead of cloning yourself, is much more sane. After all, the use of fork() is 99% of the time just to call execve(), and anything done in between is just to clean up the mess from fork(). Having a dedicated way to just create processes in a controlled fashion would have been better there. And, the other 1% is usually cases where pthread should have been used instead.

gmueckl 7y ago
Cleaning up your own process between fork and exec is hard. Several programs resort to terrible hacks like force-closing everything except file IDs 0,1,2 in a loop. Or they look into their /proc directory to discover whichnfile IDs exist, which is only marginally better. But when your process is a house of cards built on third party libraries with their own minds, there are not a lot of other options.
- tobias3 7y ago
  Use O_CLOEXEC everywhere (even third party libs). It's really annoying, but necessary. Means you need to use accept4(), dup3(), popen with an additional "e" (of course all of that needs to be feature tested, during compilation/runtime).
  - cryptonector 7y ago
    Win32 has the opposite semantics, that O_CLOEXEC is the default semantics and the app has to request the opposite if it wants it, and this causes problems too. There should have been two flags and the application should have to specify one on every handle-/fd-creating system call. Hindsight is 20/20.
  - gmueckl 7y ago
    The catch is that you may not be able to control 3rd party libraries enough to be be able to do all that. Thus all these annoying hacks. To me, the complexity of using fork() and the race conditions around pid reuse are the worst design problems of POSIX systems.

magicalhippo 7y ago

Which part of the paper made you laugh out loud? Their arguments of why fork() is not a good fit these days seemed pretty reasonable to me.

zvrba 7y ago

> Windows pretty much can't do it. Win32 API cannot do it. The underlying NT kernel can.

cryptonector 7y ago

I've been working with Unix systems for a long time. I too dislike fork(), even though I used to think it was the greatest thing. Here's a write-up of mine as to fork() being "evil": https://gist.github.com/nicowilliams/a8a07b0fc75df05f684c23c18d7db234 https://gist.github.com/nicowilliams/a8a07b0fc75df05f684c23c...