RFR: JDK-8274320: os::fork_and_exec() should be using posix_spawn
david.holmes at oracle.com
Fri Oct 22 07:19:18 UTC 2021
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
I'm surprised then that we have not encountered any such reported
deadlocks in recent years. I found this issue also somewhat illuminating:
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.
> 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
> 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
> VMError::report_and_die() seems to call fopen for the replay data file.
> There are probably more issues like that.
More information about the hotspot-runtime-dev