Moving beyond fork() + exec()
摘要
文章介绍 Unix fork () 与 exec () 系统调用（Linux 内核对应 clone () 与 execve ()）的优缺点：fork () 需复制进程状态（含内存），常紧随 exec () 丢弃拷贝，成本较高。Li Chen 提案通过 spawn templates 系统调用（create ()、spawn args ()）为重复执行相同可执行文件的场景建立模板，缓存信息并通过 spawn () 运行，减少重复成本。Mateusz Guzik 等评论指出重点应移除 fork () 部分，Christian Brauner 建议基于 pidfd 构建 builder API 支持用户态 posix spawn () 实现。结尾提及 Chen 同意该方向，未来可能引入 posix spawn () 而非当前模板。评论区满是 “Cost vs benefit?” 讨论，多条 io uring 链接，部分用户质疑内核修改必要性，提出用户态执行模板方案以规避 fork () 问题。
荐读理由
正文摘录仅列出 fork/exec 优化提案（spawn templates）及后续 posix spawn 讨论，核心信息为『Linux 内核短期未采纳 spawn templates，却可能引入 posix spawn』，这是内核层自身的技术讨论，与读者在中文小圈子 AI 工程/创业场景下的任何具体方法、洞见、变化或信号无直接匹配点。
原文
By Jonathan Corbet June 5, 2026
Since the earliest days of Unix, two of the core process-oriented system calls have been fork(), which creates a child process as a copy of the parent, and exec(), which runs a new program in the place of the current one. In Linux kernels, those system calls are better known as clone() and execve(), but the core functionality remains the same. While there is elegance to this process-creation model, there are shortcomings as well. A recent proposal from Li Chen to add "spawn templates" to the kernel will not be accepted in its current form, but it may point the way toward a new process-creation primitive in the future.
fork() is a relatively expensive system call; it must copy the entire process state (including memory) for the child process. Many optimizations have been made over the years, but a fork is still a fundamentally costly operation. To make things worse, a fork() call is often immediately followed by an exec(), which will discard all of that memory that was so carefully copied for the child. Attempts (such as vfork()) have been made over the years to optimize for this case, but the pattern still is more expensive than it could be.
Spawn templates
Chen's patch set takes an interesting approach to optimize the fork() and exec() pattern. It is focused on applications that repeatedly launch processes running the same executable; imagine, for example, a program that must run Git repeatedly to obtain information about the contents of a repository. In such cases, the program could establish a template to accelerate those invocations, spreading the setup cost across multiple operations. This template would be created with the spawn_template_create() system call:
struct spawn_template_create_args {
__aligned_u64 flags;
__s32 execfd;
__u32 exec_flags;
__aligned_u64 filename;
/* Some fields elided */
};
int spawn_template_create(struct spawn_template_create_args *args, size_t args_size);
This call will return a file descriptor representing a template for the executable file, which can be specified as either a file descriptor (execfd) or an absolute path (filename), but not both. To create the template, the kernel will open the indicated file and cache a bunch of information that will allow a process to run that file more quickly in the future.
The application in question may run a given executable many times, but each invocation is different in a number of ways. The details of a specific invocation must be placed into an instance of this structure:
struct spawn_template_spawn_args {
__aligned_u64 flags;
__aligned_u64 pidfd;
__aligned_u64 argv;
__aligned_u64 envp;
__aligned_u64 actions;
__aligned_u64 actions_len;
__aligned_u64 reserved[4];
};
The argv field is a pointer to the argument list to be passed to the program, while envp points to its environment. Changes to file descriptors and signal handling, instead, are passed through actions, which is a pointer to an array of:
struct spawn_template_action {
__u32 type;
__u32 flags;
__s32 fd;
__s32 newfd;
__aligned_u64 arg;
};
If, for example, file descriptor four should be closed in the child, the associated spawn_template_action structure would have type set to SPAWN_TEMPLATE_ACTION_CLOSE and fd set to four. Other actions exist for duplicating file descriptors, opening files, changing the working directory, and changing signal handling.
Once the spawn_template_spawn_args structure has been filled in, the new process can be run with:
int spawn_template_spawn(int template_fd,
struct spawn_template_spawn_args *args, int args_size);
Internally, this system call follows something close to the normal fork()/exec() path. Chen is careful to point out that all of the normal checks applied when executing a new file remain in place. But the cached information in the template makes the whole process faster than it was before. How much faster? Benchmark results provided in the cover letter show an improvement of about 2%, which may not seem like a lot, but it may make a difference for applications that fit the expected pattern.
Toward posix_spawn()
The most detailed review of this work was posted by Mateusz Guzik, who said: "This problem is dear to my heart and I have been pondering it on and off for some time now. The entire fork + exec idiom is terrible and needs to be retired". He pointed out that the focus of the patch set was a bit strange in that it left the fork() part of the problem untouched. That is where most of the cost lies, he said, so optimization efforts should seek to remove it from the picture. Rather than copying the current process, "creating a pristine process is the way to go".
Christian Brauner was favorable toward the goal, saying: "The idea of having a builder api for exec isn't all that crazy". His suggestion, though, was that a new API should be built on top of the existing pidfd abstraction. Without getting into any degree of detail, he said that the right approach would be to create an option to pidfd_open() to create an empty process. A series of calls to a new pidfd_config() system call would then configure this new process as desired, setting up its environment, image to execute, and more. pidfd_config() would thus be analogous to fsconfig().
An important objective for a new interface, Brauner said, would be the ability to support an implementation of posix_spawn() in user space. posix_spawn() is well suited as a replacement for the fork()/exec() pattern; developers would likely welcome a native implementation that isn't (unlike the current implementation) hiding fork() and exec() under the covers. Chen agreed that the API as broadly sketched out by Brauner seemed better, and said that future work would be in that direction. So there will be no spawn templates in the Linux kernel but, if Chen's future work comes to fruition, Linux may finally gain a proper posix_spawn() implementation instead.
| Index entries for this article | |
|---|---|
| Kernel | System calls/clone() |
| Kernel | System calls/execve() |
posix_spawn() does avoid the copy-on-write, at least sometimes
Posted Jun 5, 2026 16:49 UTC (Fri) by bluca (subscriber, #118303) [Link]
posix_spawn() does avoid the copy-on-write, at least sometimes
Posted Jun 9, 2026 1:37 UTC (Tue) by sionescu (subscriber, #59410) [Link]
io_uring
Posted Jun 5, 2026 14:45 UTC (Fri) by josh (subscriber, #17465) [Link] (14 responses)
io_uring
Posted Jun 5, 2026 15:06 UTC (Fri) by krisman (subscriber, #102057) [Link]
io_uring
Posted Jun 5, 2026 15:32 UTC (Fri) by bluca (subscriber, #118303) [Link] (6 responses)
io_uring
Posted Jun 5, 2026 15:41 UTC (Fri) by krisman (subscriber, #102057) [Link] (5 responses)
io_uring
Posted Jun 5, 2026 15:55 UTC (Fri) by bluca (subscriber, #118303) [Link] (2 responses)
io_uring
Posted Jun 5, 2026 16:09 UTC (Fri) by josh (subscriber, #17465) [Link] (1 responses)
io_uring
Posted Jun 7, 2026 7:13 UTC (Sun) by daandemeyer (subscriber, #163201) [Link]
io_uring
Posted Jun 7, 2026 3:30 UTC (Sun) by DemiMarie (subscriber, #164188) [Link]
io_uring filtering
Posted Jun 7, 2026 3:30 UTC (Sun) by DemiMarie (subscriber, #164188) [Link]
io_uring
Posted Jun 5, 2026 17:49 UTC (Fri) by calvin (subscriber, #168398) [Link] (3 responses)
io_uring
Posted Jun 5, 2026 19:56 UTC (Fri) by josh (subscriber, #17465) [Link]
io_uring
Posted Jun 6, 2026 4:53 UTC (Sat) by IAmLiterallyABee (subscriber, #144892) [Link]
io_uring
Posted Jun 8, 2026 19:20 UTC (Mon) by kreijack (guest, #43513) [Link]
io_uring
Posted Jun 5, 2026 19:36 UTC (Fri) by khim (subscriber, #9252) [Link] (1 responses)
You want to extend io_uring is some “special way”… Why? What would it buy you? Do you really spawn so many processes that normal syscalls are not enough?
Just execute the code that would perform you damn template (and yes, this very much includes io_uring if you really need to) using existing mechanisms.
No need to change anything in kernel at all, everything can be done from the userspace.
io_uring
Posted Jun 5, 2026 19:58 UTC (Fri) by josh (subscriber, #17465) [Link]
Cost vs benefit ?
Posted Jun 5, 2026 18:01 UTC (Fri) by alkbyby (subscriber, #61687) [Link] (86 responses)
Cost vs benefit ?
Posted Jun 5, 2026 18:36 UTC (Fri) by alkbyby (subscriber, #61687) [Link] (85 responses)
Cost vs benefit ?
Posted Jun 5, 2026 19:14 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (84 responses)
Cost vs benefit ?
Posted Jun 5, 2026 20:25 UTC (Fri) by alkbyby (subscriber, #61687) [Link] (83 responses)
Cost vs benefit ?
Posted Jun 5, 2026 20:44 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (82 responses)
Cost vs benefit ?
Posted Jun 5, 2026 22:03 UTC (Fri) by alkbyby (subscriber, #61687) [Link] (81 responses)
Cost vs benefit ?
Posted Jun 6, 2026 19:22 UTC (Sat) by quotemstr (subscriber, #45331) [Link] (80 responses)
Cost vs benefit ?
Posted Jun 6, 2026 21:01 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Cost vs benefit ?
Posted Jun 7, 2026 0:43 UTC (Sun) by koflerdavid (subscriber, #176408) [Link]
Cost vs benefit ?
Posted Jun 7, 2026 0:45 UTC (Sun) by intelfx (subscriber, #130118) [Link] (76 responses)
Cost vs benefit ?
Posted Jun 7, 2026 1:57 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (69 responses)
Cost vs benefit ?
Posted Jun 7, 2026 8:27 UTC (Sun) by erincandescent (subscriber, #141058) [Link] (56 responses)
The problem here is that on Linux we link against /lib/libc.so.6, and not e.g. /usr/lib/sdk/rhel-8.0/lib/libc.so.6.stub
of course working out what such "sdks" should exist and what such a stub file should look like... is a non-trivial question
Cost vs benefit ?
Posted Jun 7, 2026 9:58 UTC (Sun) by malmedal (subscriber, #56172) [Link] (52 responses)
Cost vs benefit ?
Posted Jun 7, 2026 10:14 UTC (Sun) by bluca (subscriber, #118303) [Link] (51 responses)
Cost vs benefit ?
Posted Jun 7, 2026 11:41 UTC (Sun) by malmedal (subscriber, #56172) [Link]
Cost vs benefit ?
Posted Jun 7, 2026 22:50 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (49 responses)
Cost vs benefit ?
Posted Jun 7, 2026 23:59 UTC (Sun) by bluca (subscriber, #118303) [Link] (46 responses)
Cost vs benefit ?
Posted Jun 8, 2026 2:24 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (45 responses)
Cost vs benefit ?
Posted Jun 8, 2026 10:07 UTC (Mon) by bluca (subscriber, #118303) [Link] (44 responses)
Cost vs benefit ?
Posted Jun 8, 2026 10:16 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)
Cost vs benefit ?
Posted Jun 8, 2026 11:18 UTC (Mon) by bluca (subscriber, #118303) [Link] (1 responses)
Please stop - again
Posted Jun 8, 2026 13:13 UTC (Mon) by corbet (editor, #1) [Link]
Luca, this is the second time in just a few days that I've had to ask you to stop with the personal attacks. Seriously, just stop.
Cost vs benefit ?
Posted Jun 8, 2026 11:15 UTC (Mon) by malmedal (subscriber, #56172) [Link] (40 responses)
Cost vs benefit ?
Posted Jun 8, 2026 11:22 UTC (Mon) by bluca (subscriber, #118303) [Link] (39 responses)
Cost vs benefit ?
Posted Jun 8, 2026 12:27 UTC (Mon) by malmedal (subscriber, #56172) [Link] (38 responses)
Cost vs benefit ?
Posted Jun 8, 2026 12:44 UTC (Mon) by bluca (subscriber, #118303) [Link] (37 responses)
Cost vs benefit ?
Posted Jun 8, 2026 13:14 UTC (Mon) by malmedal (subscriber, #56172) [Link] (36 responses)
Cost vs benefit ?
Posted Jun 8, 2026 13:33 UTC (Mon) by bluca (subscriber, #118303) [Link] (35 responses)
Cost vs benefit ?
Posted Jun 8, 2026 14:44 UTC (Mon) by malmedal (subscriber, #56172) [Link] (34 responses)
Cost vs benefit ?
Posted Jun 8, 2026 14:48 UTC (Mon) by bluca (subscriber, #118303) [Link] (33 responses)
Cost vs benefit ?
Posted Jun 8, 2026 16:00 UTC (Mon) by malmedal (subscriber, #56172) [Link] (32 responses)
Cost vs benefit ?
Posted Jun 8, 2026 16:15 UTC (Mon) by bluca (subscriber, #118303) [Link] (31 responses)
Cost vs benefit ?
Posted Jun 8, 2026 17:18 UTC (Mon) by malmedal (subscriber, #56172) [Link] (30 responses)
Cost vs benefit ?
Posted Jun 8, 2026 17:27 UTC (Mon) by bluca (subscriber, #118303) [Link] (26 responses)
Cost vs benefit ?
Posted Jun 8, 2026 18:36 UTC (Mon) by malmedal (subscriber, #56172) [Link] (25 responses)
Cost vs benefit ?
Posted Jun 8, 2026 18:48 UTC (Mon) by bluca (subscriber, #118303) [Link] (24 responses)
Stop here
Posted Jun 8, 2026 19:03 UTC (Mon) by jzb (editor, #7867) [Link]
Cost vs benefit ?
Posted Jun 9, 2026 8:49 UTC (Tue) by malmedal (subscriber, #56172) [Link] (22 responses)
Cost vs benefit ?
Posted Jun 9, 2026 10:32 UTC (Tue) by bluca (subscriber, #118303) [Link] (21 responses)
Cost vs benefit ?
Posted Jun 9, 2026 16:50 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (18 responses)
Cost vs benefit ?
Posted Jun 9, 2026 17:14 UTC (Tue) by bluca (subscriber, #118303) [Link] (17 responses)
Cost vs benefit ?
Posted Jun 9, 2026 17:42 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (16 responses)
Cost vs benefit ?
Posted Jun 9, 2026 18:24 UTC (Tue) by bluca (subscriber, #118303) [Link] (15 responses)
Cost vs benefit ?
Posted Jun 9, 2026 18:34 UTC (Tue) by quotemstr (subscriber, #45331) [Link] (5 responses)
Cost vs benefit ?
Posted Jun 9, 2026 18:55 UTC (Tue) by bluca (subscriber, #118303) [Link] (4 responses)
Cost vs benefit of extended discussion
Posted Jun 9, 2026 18:59 UTC (Tue) by corbet (editor, #1) [Link] (1 responses)
I vaguely recall that, once upon a time, this was an article about fork() and exec(). This discussion has clearly strayed far from that topic. Perhaps more to the point, though, it seems to be becoming increasingly circular. Perhaps it's time for all of the parties involved to let it go?
Cost vs benefit of extended discussion
Posted Jun 9, 2026 19:00 UTC (Tue) by bluca (subscriber, #118303) [Link]
Cost vs benefit ?
Posted Jun 9, 2026 19:15 UTC (Tue) by quotemstr (subscriber, #45331) [Link] (1 responses)
Cost vs benefit ?
Posted Jun 9, 2026 19:18 UTC (Tue) by daroc (editor, #160859) [Link]
Cost vs benefit ?
Posted Jun 9, 2026 18:46 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)
Cost vs benefit ?
Posted Jun 9, 2026 18:59 UTC (Tue) by bluca (subscriber, #118303) [Link] (7 responses)
Cost vs benefit ?
Posted Jun 9, 2026 19:21 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)
Cost vs benefit ?
Posted Jun 9, 2026 19:41 UTC (Tue) by bluca (subscriber, #118303) [Link] (5 responses)
Cost vs benefit ?
Posted Jun 9, 2026 20:02 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)
Cost vs benefit ?
Posted Jun 9, 2026 20:22 UTC (Tue) by bluca (subscriber, #118303) [Link] (3 responses)
Cost vs benefit ?
Posted Jun 9, 2026 21:57 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)
Cost vs benefit ?
Posted Jun 9, 2026 22:03 UTC (Tue) by bluca (subscriber, #118303) [Link]
Cost vs benefit ?
Posted Jun 10, 2026 9:14 UTC (Wed) by taladar (subscriber, #68407) [Link]
Cost vs benefit ?
Posted Jun 9, 2026 18:00 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)
Cost vs benefit ?
Posted Jun 9, 2026 18:17 UTC (Tue) by bluca (subscriber, #118303) [Link]
Cost vs benefit ?
Posted Jun 9, 2026 12:56 UTC (Tue) by mbunkus (subscriber, #87248) [Link] (2 responses)
Cost vs benefit ?
Posted Jun 9, 2026 13:12 UTC (Tue) by bluca (subscriber, #118303) [Link]
Cost vs benefit ?
Posted Jun 10, 2026 9:23 UTC (Wed) by taladar (subscriber, #68407) [Link]
Cost vs benefit ?
Posted Jun 15, 2026 5:48 UTC (Mon) by aleXXX (subscriber, #2742) [Link] (1 responses)
Cost vs benefit ?
Posted Jun 15, 2026 11:15 UTC (Mon) by malmedal (subscriber, #56172) [Link]
Cost vs benefit ?
Posted Jun 7, 2026 22:45 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
Cost vs benefit ?
Posted Jun 8, 2026 7:56 UTC (Mon) by kleptog (subscriber, #1183) [Link] (1 responses)
Cost vs benefit ?
Posted Jun 8, 2026 9:14 UTC (Mon) by malmedal (subscriber, #56172) [Link]
Cost vs benefit ?
Posted Jun 7, 2026 10:34 UTC (Sun) by quotemstr (subscriber, #45331) [Link] (2 responses)
Cost vs benefit ?
Posted Jun 7, 2026 22:59 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)
Cost vs benefit ?
Posted Jun 8, 2026 1:25 UTC (Mon) by 0xilly (subscriber, #172315) [Link]
Cost vs benefit ?
Posted Jun 8, 2026 11:46 UTC (Mon) by ballombe (subscriber, #9523) [Link] (3 responses)
Cost vs benefit ?
Posted Jun 8, 2026 18:20 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)
Cost vs benefit ?
Posted Jun 8, 2026 18:35 UTC (Mon) by farnz (subscriber, #17727) [Link] (1 responses)
Have you tried the .symver assembly directive to link against older symbol versions with a newer glibc? It should, in theory, work (albeit I haven't tested it), but it'll be painful to use because you need every object file you build to have a consistent set of imported symbols to ensure that you can dynamically link against an older glibc.
If that works, then there's room for glibc to supply a "compat" header for each older version that just sets the symbol versions to link against for every glibc signal, and for your build system to use the -include preprocessor option to force-include the right compat header in your code.
Cost vs benefit ?
Posted Jun 8, 2026 19:15 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Cost vs benefit ?
Posted Jun 8, 2026 12:10 UTC (Mon) by bluca (subscriber, #118303) [Link] (4 responses)
Cost vs benefit ?
Posted Jun 8, 2026 18:31 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)
Cost vs benefit ?
Posted Jun 8, 2026 18:34 UTC (Mon) by bluca (subscriber, #118303) [Link] (2 responses)
Cost vs benefit ?
Posted Jun 8, 2026 23:28 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (1 responses)
Cost vs benefit ?
Posted Jun 9, 2026 10:28 UTC (Tue) by bluca (subscriber, #118303) [Link]
Cost vs benefit ?
Posted Jun 7, 2026 15:43 UTC (Sun) by alkbyby (subscriber, #61687) [Link] (5 responses)
Cost vs benefit ?
Posted Jun 8, 2026 10:19 UTC (Mon) by smcv (subscriber, #53363) [Link] (4 responses)
Cost vs benefit ?
Posted Jun 8, 2026 19:01 UTC (Mon) by NYKevin (subscriber, #129325) [Link]
Cost vs benefit ?
Posted Jun 9, 2026 17:18 UTC (Tue) by alkbyby (subscriber, #61687) [Link] (2 responses)
Cost vs benefit ?
Posted Jun 9, 2026 17:22 UTC (Tue) by bluca (subscriber, #118303) [Link] (1 responses)
Cost vs benefit ?
Posted Jun 9, 2026 21:35 UTC (Tue) by alkbyby (subscriber, #61687) [Link]
libc is not a cooperative commons
Posted Jun 13, 2026 6:39 UTC (Sat) by anton (subscriber, #25547) [Link]
it's somehow imperative for them to make direct system calls, therefore defeating attempts to form a cooperative commons that doesn't involve a CPU privilege transition. Why?
libc does not provide a cooperative commons. From the beginning the C people have designed their interfaces to the system calls to deal with the shortcomings of C, in particular by introducing errno.
But ok, you might still consider this a commons of a kind. But then the C people use macros liberally, in particular for implementing errno, thus only C programs can access these features without contortions. So no, the libc interface to the system calls is no cooperative commons. There is C, in a privileged position, the language that libc implementations are designed for, and for which compatibility is guaranteed. And there are the other languages, in a position that have to accomodate every whim of a libc maintainer if they choose to use libc.
In Linux system calls provide a cleaner, more stable, and, for other languages, easier to use interface, so why should anyone who implements a language other than C use the libc interface?
Fork() in the road paper
Posted Jun 5, 2026 18:54 UTC (Fri) by joib (subscriber, #8541) [Link] (4 responses)
Fork() in the road paper
Posted Jun 5, 2026 21:33 UTC (Fri) by gutschke (subscriber, #27910) [Link] (3 responses)
Fork() in the road paper
Posted Jun 5, 2026 22:57 UTC (Fri) by malmedal (subscriber, #56172) [Link] (2 responses)
Fork() in the road paper
Posted Jun 5, 2026 23:11 UTC (Fri) by gutschke (subscriber, #27910) [Link] (1 responses)
Fork() in the road paper
Posted Jun 5, 2026 23:35 UTC (Fri) by malmedal (subscriber, #56172) [Link]
fork() + exec()
Posted Jun 5, 2026 18:55 UTC (Fri) by clugstj (subscriber, #4020) [Link] (4 responses)
fork() + exec()
Posted Jun 5, 2026 21:54 UTC (Fri) by roc (subscriber, #30627) [Link] (3 responses)
fork() + exec()
Posted Jun 5, 2026 22:07 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)
fork() + exec()
Posted Jun 9, 2026 0:09 UTC (Tue) by csamuel (✭ supporter ✭, #2624) [Link]
fork() + exec()
Posted Jun 8, 2026 21:23 UTC (Mon) by NYKevin (subscriber, #129325) [Link]
But won't someone think of the children?
Posted Jun 5, 2026 23:49 UTC (Fri) by ejr (subscriber, #51652) [Link]
The entire fork + exec idiom is terrible and needs to be retired
Posted Jun 8, 2026 10:12 UTC (Mon) by rweikusat2 (subscriber, #117920) [Link] (1 responses)
The entire fork + exec idiom is terrible and needs to be retired
Posted Jun 9, 2026 23:34 UTC (Tue) by NYKevin (subscriber, #129325) [Link]
这条对你有帮助吗？