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

[David Holmes]

On 6/10/2021 4:52 pm, Thomas Stuefe wrote:
> On Wed, 29 Sep 2021 06:11:27 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> Hi Thomas,
>>
>> There is a crucial difference between the requirements of os::fork_and_exec versus the Java Runtime.exec call - in the VM we need to use an async-signal-safe function where possible. fork() is async-signal-safe but posix_spawn is not.
>>
>> Cheers, David
> 
> Hi David,
> 
> fork() is not async-signal safe either. Since fork() can cause the execution of at-fork handlers.
> 
> https://man7.org/linux/man-pages/man7/signal-safety.7.html
> 
> 
>         *  POSIX.1-2001 TC1 clarified that if an application calls
>            fork(2) from a signal handler and any of the fork handlers
>            registered by pthread_atfork(3) calls a function that is not
>            async-signal-safe, the behavior is undefined. A future
>            revision of the standard is likely to remove fork(2) from the
>            list of async-signal-safe functions.
> 
> 
> Therefore I think we don't lose anything by moving to posix_spawn(). But we gain reliability in high-footprint scenarios.

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.

David
-----

> For me, this is an important point. Analysis options such as OnError should be very reliable. They are often used in support situations where time is short and customer patience is limited. Failing analysis causes more iterations or may make analysis even impossible.
> 
> Cheers, Thomas
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/5698
>