posix_spawn() does avoid the copy-on-write, at least sometimes [LWN.net]

posix_spawn() does avoid the copy-on-write, at least sometimes

Posted Jun 5, 2026 14:29 UTC (Fri) by smcv (subscriber, #53363)
Parent article: Moving beyond fork() + exec()

> a native implementation that isn't (unlike the current implementation) hiding fork() and exec() under the covers

posix_spawn() does at least *sometimes* avoid the copying problems of fork/exec - if there's no dedicated syscall for it, perhaps it uses vfork() and exec()? I know that recent GLib tries to use posix_spawn() as a backend for g_spawn_async() and similar functions if it can, and that was done to avoid real user-facing issues with fork/exec on low-memory systems, apparently successfully.

(Unfortunately, the things you can do in posix_spawn() are rather limited, so libraries that want to run subprocesses in a somewhat predictable execution environment, while not 100% in control of their own host process's execution environment, can't always use it - for example you can posix_spawn_file_actions_addclose() to close individual fds, but you can't do the equivalent of close_range(). So GLib still needs to use fork/exec in many cases, depending on the options passed to GLib's own APIs by the library user.)

posix_spawn() does avoid the copy-on-write, at least sometimes

Posted Jun 9, 2026 1:37 UTC (Tue) by sionescu (subscriber, #59410) [Link]

> for example you can posix_spawn_file_actions_addclose() to close individual fds, but you can't do the equivalent of close_range()

I wrote a clone of posix_spawn with some extra extensions, like specifying which FDs to keep, and close all the remaining ones: https://github.com/sionescu/libfixposix/blob/master/src/i...