On 19/10/2025 20:11, Collin Funk wrote:
Pádraig Brady <[email protected]> writes:
I think posix_spawn would be useful when exec'ing something immediately after
fork(),
as you then don't have the overhead of memory accounting for the fork.
This is especially useful when the memory used by a program is large.
For example a large sort --compress can hit this, as mentioned a little while
ago:
https://lists.gnu.org/archive/html/coreutils/2025-10/msg00059.html
I.e. this is not just a perf benefit, but can unblock some workflows.
The specific sort issue was discussed at
https://unix.stackexchange.com/a/275557/37127,
Interesting, thanks for the explanation.
I'm curious what that stackexchange user was sorting that
they ran into that issue with.
where I noted glibc's implementation was just becoming usable,
which definitely should be the case by now.
What was wrong with it previously? As far as I can tell, before
glibc-2.24 posix_spawn just did fork/vfork + exec. Were there problems
with that implementation or some issues with the earlier clone versions?
I was thinking of https://sourceware.org/PR10354
cheers,
Padraig
