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? Collin
