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

Fork() without exec() is dangerous in large programs

evanjones.ca

Post reply on HN
Print view View original

11–20 of 106 posts

Re: Fork() without exec() is dangerous in large programs

#11

Post by xroche »

rdtsc wrote: post #8

Yap. Erlang 19 (latest version) switched to using a smaller spawner executable and spawns all OS processes from there by forking. So it forks something restricted and small not the whole VM. Here are the details of how it works: https://github.com/erlang/otp/blob/a5256e5221aff30f6d2cc7fab... They also claim a 3-5x speedup for launching external commands because of it. So there is a nice performance boost as well. So…

This is not a bad strategy, especially because between the moment you fork() and the child calls exec(), you have a lot of memory regions shared in copy-on-write (because it would be Too costly to actually duplicate the universelle). Which means that busy threads writing in memory in the parent area will trigger minor page faults, possibly impacting performances...

Re: Fork() without exec() is dangerous in large programs

#13

Post by pjmlp »

caf wrote: post #2

In my opinion, it's libraries that secretly use threads under the covers (but still access state shared with the rest of the program like the malloc heap) that are what's dangerous.

What is dangerous is that the interactions between threads and processes aren't part of POSIX standard and its behavior is OS specific across UNIX implementations.

This isn't an issue on non-UNIX OSes.

Re: Fork() without exec() is dangerous in large programs

#14

Post by ej_campbell »

xroche wrote: post #7

fork() is not per se "dangerous" in such context. You just have to be careful enough and only use asynchronous-signal-safe fonctions, as you would do in a signal handler (see https://www.securecoding.cert.org/confluence/display/c/SIG30... ) Typically calls such as malloc(), printf() etc. are strictly forbidden in the child after a fork().

Only if your app is multi-threaded. Unfortunately, many apps are multi-threaded "under the covers" due to libraries that spawn threads, so you need to be careful.

This post does the best job explaining the issue: http://www.linuxprogrammingblog.com/threads-and-fork-think-t...

Re: Fork() without exec() is dangerous in large programs

#16

Post by adrianratnapala »

eridius wrote: post #10
caf wrote: post #2

In my opinion, it's libraries that secretly use threads under the covers (but still access state shared with the rest of the program like the malloc heap) that are what's dangerous.

I completely disagree. The only part of this that seems dangerous is the fact that it can turn a single-threaded program into a multi-threaded one, and the only real problem there is it makes fork-without-exec unsafe. But fork-without-exec is basically unsafe anyway unless you can absolutely guarantee that nothing has ever spawned a thread. Meanwhile, preventing libraries from using threading under the covers basical…

This is the very first time I have heard about fork-without-exec as dangerous, but it is not the first time I have heard about having to be careful about libraries and hidden threads.

The thing is that any thread you launch is a big piece of machinery and your attempt to hide it is inevitably going to be a leaky abstraction.

Re: Fork() without exec() is dangerous in large programs

#17

Post by wruza »

pjmlp wrote: post #13
caf wrote: post #2

In my opinion, it's libraries that secretly use threads under the covers (but still access state shared with the rest of the program like the malloc heap) that are what's dangerous.

What is dangerous is that the interactions between threads and processes aren't part of POSIX standard and its behavior is OS specific across UNIX implementations. This isn't an issue on non-UNIX OSes.

How many non-unixes do have fork_without_exec()?

Re: Fork() without exec() is dangerous in large programs

#18

Post by ahoka »

saynsedit wrote: post #12

Face the fact, fork() is fundamentally flawed!

I would like to see the reasons this comment was down-voted. It is true that fork(2) is simple and elegant design, but it involves a huge accidental complexity and hidden implications like in the original article. There is a reason that Linux has clone(2) underneath.

Re: Fork() without exec() is dangerous in large programs

#19

Post by astrodust »

ahoka wrote: post #18
saynsedit wrote: post #12

Face the fact, fork() is fundamentally flawed!

I would like to see the reasons this comment was down-voted. It is true that fork(2) is simple and elegant design, but it involves a huge accidental complexity and hidden implications like in the original article. There is a reason that Linux has clone(2) underneath.

Every method has limitations. If you want to call these flaws that's just semantics.

Re: Fork() without exec() is dangerous in large programs

#20

Post by pjmlp »

wruza wrote: post #17
pjmlp wrote: post #13

Earlier quoted context omitted.

What is dangerous is that the interactions between threads and processes aren't part of POSIX standard and its behavior is OS specific across UNIX implementations. This isn't an issue on non-UNIX OSes.

How many non-unixes do have fork_without_exec()?

Most non-UNIX OSes only have exec(), not fork().

Hence why fork() is just kind-of implemented on their POSIX compatibility layers.

In UNIX it is only an issue, because IEEE doesn't want to set in stone in POSIX how threads, signals and processes should interact, due to the way threads were added to UNIX.

Post reply on HN