Moving beyond fork() + exec() • Hacker News Board

Re: Moving beyond fork() + exec()

#101

Post by uecker » Sat, Jun 06, 2026, 5:12 PM UTC

garaetjjte wrote: post #63

uecker wrote: post #26

The elegance of the fork() + exec() model is that every kind of configuration can be done after the fork using all the usual APIs. Every attempt to replace it with a combined call that I have seen so far seemed fundamentally poorer because it needs to add all configuration options as parameters to the call and then do this in away that you can extend it later and does not become a mess.

That's mostly papering over design mistake that most syscalls doesn't accept target pid. Otherwise you could just create suspended process, configure it with syscalls that explicitly take target pid, and start it.

Maybe, I am not saying fork() + exec() model couldn't be improved, but most people saying it is "terrible" and it needs to die seem to go on to propose something substantially worse.

Re: Moving beyond fork() + exec()

#102

Post by yxhuvud » Sat, Jun 06, 2026, 5:13 PM UTC

1718627440 wrote: post #39

sanderjd wrote: post #17

I just ran into this recently, where I had an obscure bug caused by needing to close more file descriptors in the forked process. "I want a clone of the current process" is just way less common in my experience than "I want a completely new process". It feels crazy that we don't have a way to directly express the latter thing, and can only approximate it by cloning and then fixing things up in post.

But you generally want to communicate with that process, so you do need to setup e.g. file descriptors and stuff, which needs information from the parent process to be passed.

Yes, you do want to pass in some stuff. But by default you get every single open file descriptor and a copy of every single stack that any threads use for execution.

It shares way too much, and have huge use cases where it is really, really bad.

Re: Moving beyond fork() + exec()

#103

Post by yxhuvud » Sat, Jun 06, 2026, 5:15 PM UTC

7jjjjjjj wrote: post #90

sanderjd wrote: post #17

I just ran into this recently, where I had an obscure bug caused by needing to close more file descriptors in the forked process. "I want a clone of the current process" is just way less common in my experience than "I want a completely new process". It feels crazy that we don't have a way to directly express the latter thing, and can only approximate it by cloning and then fixing things up in post.

>It feels crazy that we don't have a way to directly express the latter thing Isn't that what posix_spawn is for?

And how do you think posix_spawn is implemented?

Re: Moving beyond fork() + exec()

#104

Post by JdeBP » Sat, Jun 06, 2026, 5:15 PM UTC

amluto wrote: post #99

chasil wrote: post #92

Earlier quoted context omitted.

Well, Cygwin and Busybox have shown me that fork-heavy activities are about 100x slower on Windows than Linux. The Windows approach may be correct, but it suffers in performance from the POSIX perspective. I have heard that WSL1 iimproves this.

Linux has worked pretty hard to optimize fork(). This doesn’t mean that fork() is a good idea. Windows does not historically depend on fork(), so there was no native fork(), so Cygwin kludged it up.

Actually, there is a native fork. There had to be, as POSIX personality support was a part of the Windows NT 3.1 design. What there wasn't was a Win32 form of fork. The Native API for Windows NT allowed it quite straightforwardly.

Re: Moving beyond fork() + exec()

#105

Post by toast0 » Sat, Jun 06, 2026, 5:15 PM UTC

7jjjjjjj wrote: post #90

sanderjd wrote: post #17

I just ran into this recently, where I had an obscure bug caused by needing to close more file descriptors in the forked process. "I want a clone of the current process" is just way less common in my experience than "I want a completely new process". It feels crazy that we don't have a way to directly express the latter thing, and can only approximate it by cloning and then fixing things up in post.

>It feels crazy that we don't have a way to directly express the latter thing Isn't that what posix_spawn is for?

posix_spawn addresses the need from userspace. Under the hood, it's still doing more or less a fork/exec, with the baggage that comes with it. A syscall would be nicer.

Re: Moving beyond fork() + exec()

#106

Post by nvme0n1p1 » Sat, Jun 06, 2026, 5:22 PM UTC

theK wrote: post #94

mort96 wrote: post #79

Earlier quoted context omitted.

The problem with fork isn't really that it's slow. The problem is that if you want it to be not-slow, it locks you into a bunch of OS design decisions: you more or less need a memory subsystem where all writable pages are refcounted and copy-on-write when the refcount is bigger than 1, and you need overcommit. Now these decisions aren't objectively bad , but they have significant trade-offs and it's probably not a go…

Didn't he just say that fork turns out to be comparatively faster to the non-fork samples we get? Ie Linux spawns processes faster than Microsoft's kernels?

We don't have any broadly used non-fork samples. Windows, macOS, and Linux all have fork. So the presence of fork can't be the reason for the performance difference.

(Windows's fork is called ZwCreateProcess)

Re: Moving beyond fork() + exec()

#107

Post by pjmlp » Sat, Jun 06, 2026, 5:27 PM UTC

zozbot234 wrote: post #78

pjmlp wrote: post #70

Earlier quoted context omitted.

Because that OS best practices is to use threads. Traditionally Windows applications that create processes all the time come from UNIX heritage. Contrary to UNIX, Windows NT was designed with threads first mentality, from the get go. While on UNIX they were added after fact, and to this day there are gotchas mixing posix threads with signals, fork and exec.

Windows was designed with threads-first mentality because on pre-386 machines you don't have viable process memory protection, so your tasks share memory by necessity. This is not a great argument.

Windows NT!

Misread on purpose to make a point?

Re: Moving beyond fork() + exec()

#108

Post by marcosdumay » Sat, Jun 06, 2026, 5:29 PM UTC

mort96 wrote: post #79

anarazel wrote: post #58

Earlier quoted context omitted.

It is somewhat interesting that the most widely used "big" OS that doesn't use fork, i.e. Windows, has dog slow process creation... I agree that there should be non-fork primitives, I'm just not that sure that performance is the best argument.

The problem with fork isn't really that it's slow. The problem is that if you want it to be not-slow, it locks you into a bunch of OS design decisions: you more or less need a memory subsystem where all writable pages are refcounted and copy-on-write when the refcount is bigger than 1, and you need overcommit. Now these decisions aren't objectively bad , but they have significant trade-offs and it's probably not a go…

CoW is probably a good idea whether you use fork or not. Or rather, fork is probably a better option than just exec exactly because it can benefit from CoW.

At least on systems with virtual addressing. If you want to go into physical addressing, then yes, maybe it's a problem. But Linux will never touch anything with physical addressing, so I don't see what people are complaining about.

Re: Moving beyond fork() + exec()

#109

Post by JdeBP » Sat, Jun 06, 2026, 5:29 PM UTC

epcoa wrote: post #93

zozbot234 wrote: post #78

Earlier quoted context omitted.

Windows was designed with threads-first mentality because on pre-386 machines you don't have viable process memory protection, so your tasks share memory by necessity. This is not a great argument.

This is not true. NT never had fork, was always based on the assumption of an MMU and Dave Cutler was a well known fork hater in the 80s long before this paper came out and made it cool to be so. By the time Windows 95 was out, the baseline was 386 with an MMU. CreateThread was initially designed for NT in 1993 though (which didn’t support pre-386 CPUs).

As mentioned elsewhere on this page, Windows NT had fork from the start. Vide NtCreateProcess and what happens if an image file is not explicitly supplied.

* https://computernewb.com/~lily/files/Documents/NTDesignWorkb...

Re: Moving beyond fork() + exec()

#110

Post by yxhuvud » Sat, Jun 06, 2026, 5:31 PM UTC

burnt-resistor wrote: post #40

> "If you are repeatedly creating large processes, you are already doing it wrong. The fix is in user space, not the kernel." Every couple of years, someone claims they have "the solution" implying everyone else who came before them didn't know what they were doing.

It can also mean that neither the hardware side or the software side is static, but change over time. That means that their demands and what they allow also change over time. This leads to the insight that what was perhaps a good idea on 70s hardware/software is not necessarily a good, or even ok, idea 50 years later on modern hardware executing OSes and programs that have been kept up to date.