Fork has really weird semantics, and a lot of fun gotchas around managing resources. Good riddance?
> Good riddance?
Regardless of this paper, I don't see its use declining significantly any time soon.
A fork() in the road
11–20 of 184 posts
Re: A fork() in the road
#12Earlier quoted context omitted.
It's suggesting posix_spawn, which is standardized and has nothing to do with Microsoft.
> Just as a programming course would not today begin with goto, we suggest teaching either posix_spawn() or CreateProcess(), and then introducing fork as a special case with its historic context (§2). Or CreateProcess(), which has a lot to do with microsoft.
It's just the equivalent, not EEE.
Re: A fork() in the road
#13Okay, 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.
I thought Linux had clone which glibc called for their implementation of fork.
Re: A fork() in the road
#14Earlier quoted context omitted.
> Just as a programming course would not today begin with goto, we suggest teaching either posix_spawn() or CreateProcess(), and then introducing fork as a special case with its historic context (§2). Or CreateProcess(), which has a lot to do with microsoft.
Yeah, if you're using Windows you aren't going to be able to use it. Or are you suggesting that Microsoft should implement posix_spawn?
[deleted]
Re: A fork() in the road
#15Earlier quoted context omitted.
> Just as a programming course would not today begin with goto, we suggest teaching either posix_spawn() or CreateProcess(), and then introducing fork as a special case with its historic context (§2). Or CreateProcess(), which has a lot to do with microsoft.
Yeah, if you're using Windows you aren't going to be able to use it. Or are you suggesting that Microsoft should implement posix_spawn?
Can't you use posix_spawn() with WSL and your favorite POSIX-compatible libc implementation?
Re: A fork() in the road
#16I havent read the entire thing yet, but reading from "replacing fork" to the end it reads too much like embrace extend extinguish.
Nowhere there did the authors "embrace" fork(). Quite the contrary.
While the article points out that the NT kernel natively supports fork, it certainly isn't arguing for any extension of the call.
So all we're left with is "extinguish", which this article certainly does. And it is persuasive. I will look at posix_spawn() for my own code in the future.
Re: A fork() in the road
#17I 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 an alternative to fork/exec, therefore fork/exec is better than any alternative." I can imagine all kinds of reasons for the observed behavior, few of which would prove that fork is a good model. But I still want to know what's going on.
Re: A fork() in the road
#18It points out that "1304 Ubuntu packages (7.2% of the total) calling fork, compared to only 41 uses of the more modern posix_spawn()".
In section 7 it suggests "We should therefore strongly discourage the use of fork in new code, and seek to remove it from existing apps."
Is anyone here going to help work on changing those 1304 packages?
I have already over-volunteered for thankless FOSS tasks like this, so I know it won't be me.
Re: A fork() in the road
#19I 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…
This probably isn't the technical explanation your looking for, but, in general, processes on Windows and processes on Unix aren't the same--or, at least, they're not meant to be used the same way. Creating lots of small processes on Windows has long been discouraged and considered poor design, whereas the opposite is true on Unix.
One could probably argue that processes on Windows need to be lighter-weight now that sandboxing is a common security practice. These days, programs like web browsers opt to create a large number of processes both for security and stability purposes. In much the same way that POSIX should deprecate the fork model, Windows should provide lighter-weight processes.
Re: A fork() in the road
#20It points out that "1304 Ubuntu packages (7.2% of the total) calling fork, compared to only 41 uses of the more modern posix_spawn()". In section 7 it suggests "We should therefore strongly discourage the use of fork in new code, and seek to remove it from existing apps." Is anyone here going to help work on changing those 1304 packages? I have already over-volunteered for thankless FOSS tasks like this, so I know it…
There are things that don't fit the posix_spawn limitations, especially with fd or capability manipulation.