RFR: 8291067: macOS should use O_CLOEXEC instead of FD_CLOEXEC

Gerard Ziemski gziemski at openjdk.org
Tue Aug 23 20:45:33 UTC 2022


On Mon, 1 Aug 2022 22:34:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is not a **workaround** but an improvement to the robustness of the code, that applies equally to both Linux and macOS, by taking an advantage of what once was a new feature, but now is just a more reliable mechanism for making sure that the forked/child process does not get access to unintended "leaked" file descriptor from the parent. The original comment came from Linux, but we can change it, to apply equally to both Linux/macOS.
>> 
>> I will refactor this common POSIX code, though they are not 100% exactly the same - Linux uses `open64()`, while macOS uses `open()`.
>
> The comment says:
> 
>> On ancient Linux kernels the O_CLOEXEC flag will be ignored and we fall back to using FD_CLOEXEC (see below).
> 
> so that is a workaround to handle ancient Linux kernels, and such a workaround has no meaning for BSD unless it too has ancient versions that ignored O_CLOEXEC.
> 
> That said, how ancient are we talking about? That comment may be irrelevant today given the minimum supported kernel versions we have.

I have tested O_CLOEXEC on macOS and it is available even at 10.9 I don't have hardware that can go earlier than that.

So it looks like on macOS we don't need the fallback, however, macOS is not the only BSD OS that we need to consider (?)

Should we leave the fallback for other BSD platforms?

-------------

PR: https://git.openjdk.org/jdk/pull/9663


More information about the hotspot-runtime-dev mailing list