RFR: JDK-8274320: os::fork_and_exec() should be using posix_spawn

[Florian Weimer]

* David Holmes:

> Sorry but I have to disagree. fork() is async-signal-safe, but if an
> at-fork handler is not, then all bets are off - that is fine, it is
> the best we can do. But posix_spawn makes no claim to any kind of 
> async-signal safety so we very much do lose something by switching to
> it IMO.

Sorry, I didn't see the thread until now.

The glibc implementation of fork is not async-signal-safe even if the
process has not installed any fork handlers.  Our (downstream)
perspective is captured here:

  Using the fork function in signal handlers
  <https://access.redhat.com/articles/2921161>

The current implementation of posix_spawn in glibc is async-signal-safe,
I think.  I would have to ask on libc-alpha if we can make this official
in any way.  The current musl implementation seems to be safe as well.

The glibc implementation of posix_spawn has changed substantially over
the years, and I can dig through the history to make sure it has not
changed materially.  What's the oldest glibc release you still need to
support?

Other functions in the posix_spawn corner (for maintaining file actions)
are definitely not safe because they call malloc internally, but the
current patch does not use them.

When used carefully, vfork can be made async-signal-safe.  But you
really have to block signals before calling it, and in the subprocess,
restore the signal handler disposition to SIG_DFL, and then unblock the
signals.  Otherwise some signal handler might run with a
slightly-incorrect TCB.  (Historic posix_spawn implementations did not
do the signal handlers dance.)  At least vfork does not run fork
handlers.

VMError::report_and_die() seems to call fopen for the replay data file.
There are probably more issues like that.

Thanks,
Florian