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

41–50 of 184 posts

Re: A fork() in the road

#41

Post by arghwhat »

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(). 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.

Re: A fork() in the road

#43

Post by pjmlp »

voldacar wrote: post #33

Microsoft can criticize fork() all they want, but if they were to make something similar it would just be 50 lines of boilerplate in the unreadable windows API

fork() is also missing from every other OS that isn't an UNIX clone.

Re: A fork() in the road

#44

Post by mort96 »

the_mitsuhiko wrote: post #39
spc476 wrote: post #37

Earlier quoted context omitted.

Between the `fork()` and an `exec()`, I can: * redirect stdin, stdout, and stderr * open files that might be needed and close files that aren't * change process limits * drop privileges * change the root directory * change namespaces And there are a few other things I am probably forgetting.

And ideally all these things become properties to a configuration object which is then used to spawn a process.

I'm not sure I agree it's the ideal way to do it. That's a heck of a lot of work for one function to do, and it necessarily duplicates the functionality of a ton of other functions. And that's ignoring the fact that forking without ever exec'ing can be really useful in many cases.

I haven't yet read the paper, but considering the incredible simplicity from the programmer's PoV that fork provides, and the fact that at least Linux makes it pretty god damn fast, especially compared to Windows' non-forking model, I can't really see myself agreeing with their conclusion.

Re: A fork() in the road

#45

Post by richardwhiuk »

muststopmyths wrote: post #30
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…

If I had to guess, I'd point to DLLs. The minimal Windows process loads probably half a dozen, plus the entry points are called in a serialized manner.

Pretty much identical to shared objects on Linux

Re: A fork() in the road

#46

Post by eesmith »

mort96 wrote: post #44
the_mitsuhiko wrote: post #39

Earlier quoted context omitted.

And ideally all these things become properties to a configuration object which is then used to spawn a process.

I'm not sure I agree it's the ideal way to do it. That's a heck of a lot of work for one function to do, and it necessarily duplicates the functionality of a ton of other functions. And that's ignoring the fact that forking without ever exec'ing can be really useful in many cases. I haven't yet read the paper, but considering the incredible simplicity from the programmer's PoV that fork provides, and the fact that at…

When you read the paper, you'll see this covered in section 6 ("REPLACING FORK") subsection "Low-level: Cross-process operations"

> While a spawn-like API is preferred for most instances of starting a program, for full generality it requires a flag, parameter, or new helper function controlling every possible aspect of process state. It is infeasible for a single OS API to give complete control over the initial state of a new process. ...

> clean-slate designs [e.g., 40, 43] have demonstrated an alternative model where system calls that modify per-process state are not constrained to merely the current process, but rather can manipulate any process to which the caller has access ...

> Retrofitting cross-process APIs into Unix seems at first glance challenging, but may also be productive for future research.

Re: A fork() in the road

#48

Post by eesmith »

wbl wrote: post #20
eesmith wrote: post #18

It 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.

Yes, certainly. The paper covers many of those limitations.

The goal is not "remove", but "seek to remove". The relevant definition of "seek" here is "to make an attempt" says https://www.merriam-webster.com/dictionary/seek .

How many of those 1304 Ubuntu packages require fork()? Are there benefits to replacing (say) 1283 of them with posix_spawn()?

Re: A fork() in the road

#49

Post by SifJar »

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…

Others have mentioned about DLLs being pulled in, following post might be interesting:

https://randomascii.wordpress.com/2018/12/03/a-not-called-fu...

Re: A fork() in the road

#50

Post by gmueckl »

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…

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.
Post reply on HN