>Actually I mean a *directory* that is guaranteed to exist (and meanwhile
>unexecutable): so /dev here.
Indeed, /dev should work; but using it still makes me queasier than
crafting a nonexistent path. The mkstemp thing works, so, not going to
change it to save a couple of syscalls in a configure test. :)
>Well I was intending to suggest that we simpliy avoided posix_spawn*()
>where it disagreed with posix_spawn(3p); that is to say simply replacing
>all previous `#ifdef HASPOSIXSPAWN' conditions with `#if (defined
>HASPOSIXSPAWN) && (!defined SKALIBS_HASPOSIXSPAWNEARLYRETURN)'. After
>all it seems to me child_spawn*() is not used that prevalently, so the
>performance penalty is really minor; of course, feel free to correct me.
Yes, falling back to fork+exec when posix_spawn is bad is an option,
and I would probably have done just that if I hadn't been pointed to
the existence of waitid() to achieve the "test whether a child is dead
without reaping it" thing, without which there can be no workaround.
But posix_spawn is more than a performance thing. The point of this
interface is that its implementation doesn't have to be vfork+exec
internally; it was precisely designed to allow spawning processes on
nommu machines, where vfork and fork are basically impossible. So,
using posix_spawn wherever possible helps with portability as well.
Of course, it doesn't matter for glibc, and it doesn't matter for s6
which needs fork anyway. And chances are that platforms that
implement posix_spawn() with internals that are *not* fork+exec will
not make it return before the spawning has really succeeded. But still,
it's nice to make sure it can be used wherever it exists.
If you don't like the workaround, nobody's preventing you from using
--with-sysdep-posixspawn=no manually. ;)
--
Laurent
Received on Thu Jun 29 2023 - 13:04:33 CEST