fork() + exec() [LWN.net]

fork() + exec()

Posted Jun 5, 2026 18:55 UTC (Fri) by clugstj (subscriber, #4020)
Parent article: Moving beyond fork() + exec()

If you are repeatedly creating large processes, you are already doing it wrong. The fix is in user space, not the kernel.

to post comments

fork() + exec()

Posted Jun 5, 2026 21:54 UTC (Fri) by roc (subscriber, #30627) [Link] (3 responses)

I came here to say this!! If, as a userspace developer, you really care about performance there are many tools available to you today to mitigate the cost of fork+exec, some of which reach much higher levels of performance than creating new process ever can.

Obviously the most efficient thing you can do is not use another process. Get the functionality into a library and call it in your current process.

If you do need a separate process for some reason (e.g., resource management or sandboxing), create a persistent subprocess and reuse it many times.

If for some reason you need lots of separate subprocesses, use the zygote pattern: fork+exec one zygote process, then every time you need a new subprocess, fork the zygote.

There are edge cases where these don't apply, but adding complex new kernel interfaces that give tiny wins on edge cases does not seem like a good idea.

fork() + exec()

Posted Jun 5, 2026 22:07 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

A lot of software might be _avoiding_ the subprocesses exactly because they are so horrible. In my case, we actually used a "process runner" server in one project to avoid forking in a large Java app. We needed it to do text extraction from Microsoft documents and for image parsing/resizing.

fork() + exec()

Posted Jun 9, 2026 0:09 UTC (Tue) by csamuel (✭ supporter ✭, #2624) [Link]

There's another example from the HPC community - the batch system Slurm has a slurmctld which handles the queue of active and pending jobs and can get very large when you've a big queue (10s of GBs of RAM). It also used to fork/exec to do things like run certain scripts (when configured) at various times of the job lifecycle and (which we would see more commonly) send emails when a job started/completed/failed (depending on which options the user selected at job submission time). When you can be starting and ending many jobs per second that became... suboptimal.

So SchedMD (who maintain Slurm) decided to implement a separate daemon (slurmscriptd) which was forked from slurmctld at startup and then it would be sent messages for things to do on its behalf. That relieved massively the overhead of continual fork/exec a huge process for this.

All the best,
Chris

fork() + exec()

Posted Jun 8, 2026 21:23 UTC (Mon) by NYKevin (subscriber, #129325) [Link]

> If for some reason you need lots of separate subprocesses, use the zygote pattern: fork+exec one zygote process, then every time you need a new subprocess, fork the zygote.
>
> There are edge cases where these don't apply, but adding complex new kernel interfaces that give tiny wins on edge cases does not seem like a good idea.

Most of those edge cases are probably covered by some obscure config option in systemd (which is already designed to execute arbitrary programs in arbitrary environments). But nobody wants to faff with systemd config files, hence everyone ends up reinventing the wheel instead.

I think the real win would be getting systemd to provide a nice clean posix_spawn-flavored programmatic interface so that you don't have to deal with unit files. Or if such an interface already exists, evangelizing it and getting people to use it.