Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A fork() in the road

microsoft.com

Post reply on HN
Print view View original

101–110 of 184 posts

Re: A fork() in the road

#101

Post by zbentley »

arghwhat wrote: post #41
Solomoriah wrote: post #2

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.

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…

> And, the other 1% is usually cases where pthread should have been used instead.

Ummmm. No. Threads are a much harder API to get right. They can work in this area, but that's not the same as saying they're right for all/most cases in this area.

I think a sizable part of that remaining 1% (if it is that low) are programs that leverage fork as the very powerful right tool for the job. Many of those also happen to be widely-used programs crucial for the operation of web services and large-data-set processing.

Re: A fork() in the road

#102

Post by evmar »

ktpsns wrote: post #68

Can anybody elucidate about why fork() is still used in Chromium or Node.js? They are not old-grown traditional forking Unix servers (unlike Apache or the mentioned databases in the paper). I would expect them to implement some of the alternatives and having fork() only as a fallback in the code (i.e. after a cascade of #ifdefs) if no other API is available. Therefore, I wonder where the fork() bottlenecks really app…

Chrome on Windows uses CreateProcess, and Windows came first, so Chrome is mostly architected around an approach that would fit posix_spawn better. However, fork has some benefits that I went into here:

http://neugierig.org/software/chromium/notes/2011/08/zygote....

Re: A fork() in the road

#103

Post by stirfrykitty »

We already have posix_spawn. I guess MS isn't aware of this.

Methinks MS need to focus on their own issues and leave the nix world alone. While many people find their involvement in FOSS welcome, I do not and never have. They are still a for-profit company beholden to shareholders.

The purchase by MS of GitHub may, again, be welcomed by many, but I find it disastrous. I smell triple E here no matter what anyone says. This is why distros like Debian and Slackware are still so important. All nix needs to do is start adopting MS ideas and then it's a matter of time before distros adopt disastrous code like systemd. MS does want to control everything around them like every other for-profit company. I cannot see this any other way. They are involved for their own good, for things like Azure and their own "cloud". MS needs to focus on their own garden and not that of *nix. I always have and always will prefer the "us and them" mentality when dealing with MS. Don't forget EEE. It's still a reality should you care to look hard enough.

Re: A fork() in the road

#104

Post by HappyJoy »

stirfrykitty wrote: post #103

We already have posix_spawn. I guess MS isn't aware of this. Methinks MS need to focus on their own issues and leave the nix world alone. While many people find their involvement in FOSS welcome, I do not and never have. They are still a for-profit company beholden to shareholders. The purchase by MS of GitHub may, again, be welcomed by many, but I find it disastrous. I smell triple E here no matter what anyone says.…

The paper mentions posix_spawn... so I guess they are aware

Re: A fork() in the road

#105

Post by alkonaut »

DblPlusUngood wrote: post #92
alkonaut wrote: post #57

Earlier quoted context omitted.

I can’t answer for Nginx but normally on windows if you want “worker processes” you just start N of them and have them read work from a shared memory queue. That is, workers live longer than the tasks they perform. If one crashes, a new one is spawned. This does seem like a more sensible way of doing things than forking tbh. It isolates work in processes but doesn’t pay for process creation per request.

Is recovery of a shared memory queue after one of the workers crashes even possible, in general? (what if the worker crashed before releasing a lock?)

I’m not sure how this is usually done but I’d avoid locks at nearly any cost and try to use a lock-free spmc queue such as https://github.com/tudinfse/FFQ

Re: A fork() in the road

#106

Post by naasking »

stirfrykitty wrote: post #103

We already have posix_spawn. I guess MS isn't aware of this. Methinks MS need to focus on their own issues and leave the nix world alone. While many people find their involvement in FOSS welcome, I do not and never have. They are still a for-profit company beholden to shareholders. The purchase by MS of GitHub may, again, be welcomed by many, but I find it disastrous. I smell triple E here no matter what anyone says.…

Talk about uncharitable. MS Research produces world-class research. They don't just research Windows, they do research in all operating systems, programming languages and more.

Re: A fork() in the road

#107

Post by naasking »

sfink wrote: post #17

I read the paper, and they make a lot of good points about fork's warts. But I really wanted some explanation of why Windows process startup seems to be so heavyweight. Why does anything that spawns lots of little independent processes take so bloody long on Windows? I'm not saying "lots of processes on Windows is slow, lots of processes on Linux is fast, Windows uses CreateProcess, Linux uses fork, CreateProcess is…

Microsoft Research doesn't just do research on Windows. They employ lots of researchers that are free to pursue many different topics.

Re: A fork() in the road

#108

Post by [deleted] »

stirfrykitty wrote: post #103

We already have posix_spawn. I guess MS isn't aware of this. Methinks MS need to focus on their own issues and leave the nix world alone. While many people find their involvement in FOSS welcome, I do not and never have. They are still a for-profit company beholden to shareholders. The purchase by MS of GitHub may, again, be welcomed by many, but I find it disastrous. I smell triple E here no matter what anyone says.…

[deleted]

Re: A fork() in the road

#110

Post by afiori »

kazinator wrote: post #86
afiori wrote: post #85

Earlier quoted context omitted.

Also levels of abstraction compose. > Booting a system doesn't compose; Actually this is false, virtual machine and hypervisors allow to boot a system inside another system

Virtual machines can be forked processes, and contain operating systems with forked processes, some of which are virtual machiens ... fork composes!

as a function obviously, the point is that it does not compose easily with other abstractions. That is every other library and OS functionality needs to be fork-aware.

spawn do not have this requirement.

Post reply on HN