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

[David Holmes]

Hi Florian,

On 22/10/2021 5:34 am, Florian Weimer wrote:
> * 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>

I'm surprised then that we have not encountered any such reported 
deadlocks in recent years. I found this issue also somewhat illuminating:

https://sourceware.org/bugzilla/show_bug.cgi?id=4737

especially the report that fork() is no longer required to be 
async-signal-safe, but IIUC neither is posix_spawn, so we're left with 
no way to implement this functionality in a sound way and must hope for 
the best from the implementation. That's not very satisfactory. But in 
light of this I can't really reject the change to use posix_spawn on the 
grounds that fork() is safer.

Cheers,
David
-----

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