Re: What is GLibc's policy on what is safe to use after a fork from a multithreaded program?

[Steven Stewart-Gallus <sstewartgallus00 at mylangara dot bc dot ca>]

> But you do call execve eventually?

Yes.

> How does this prevent using posix_spawn?

I need to fork, get the pid and then write to the value of the
LISTEN_PID environment variable. This is impossible with posix_spawn
and having GLibc adding custom code to posix_spawn to support this
would be stupid.

> We could add additional error reporting.  The standard trick to
> detect execve success is to read from a pipe whose other end has the
> close-on-exec bit set.

This is a different trick than the one I am thinking about.  I
currently use the pipe trick and a really ugly hack for something
else. posix_spawn should do the pipe trick but not my ugly hack.
Incidentally, it's also possible to do a similiar trick using mmap
instead.

My trick is a really ugly hack and not really needed for most
cases. I'm probably not going to add it in to my own program but it
might be worth it for a system that has to work really hard to support
critical conditions. If I needed to support such conditions though I
might actually be using a different libc that's much smaller and
easier to audit any ways though.

So the really ugly hack is where one creates a pipe and sets one end
to generate a stop signal when the read end becomes ready to
read. Then one can wait on the forked child until it execs whereupon
the write end of the pipe is closed and the read end becomes read to
read with zero bytes and signals the forked child to stop. Finally,
one restarts the process if it is stopped or one deals with the
notification that the process was killed and report ENOMEM. Like I
said though, it's really ugly and most systems won't need to support
this use case any ways.

I really wish that there was a way to tell if a process was killed by
an out of memory error instead of just a generic SIGKILL signal
because that would solve the case in a much better and more generic
way.

Thank you,
Steven Stewart-Gallus