RFR: 8291067: macOS should use O_CLOEXEC instead of FD_CLOEXEC
Thomas Stuefe
stuefe at openjdk.org
Fri Aug 26 16:47:11 UTC 2022
On Fri, 26 Aug 2022 16:08:37 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:
>> Is there anything to suggest any BSD system has ever had this issue? This seems a Linux specific workaround that has no place on macOS or BSD.
>
> If you look at _fcntl.h_ you will find:
>
>
> #if __DARWIN_C_LEVEL >= 200809L
> #define O_CLOEXEC 0x01000000 /* implicitly set FD_CLOEXEC */
> #endif
>
>
> so that suggests that `O_CLOEXEC` was not always available on macOS, so I assume same holds true for other BSD os'es?
>
> We could tweak the BSD code to statically account for the availability of `O_CLOEXEC` with `#ifdef `, but why not re-use Linux code and do it dynamically as needed?
>
> On Linux this accounts for the real possibility of kernel ignoring `O_CLOEXEC` and on BSD the workaround would be a actually a fallback on those platform that plain did not support `O_CLOEXEC` at all.
>
> We could tweak the comment to reflect these assumptions.
Hi Gerard,
sorry, I'm with @dholmes-ora on this one. Copying Linux comments like this is not really helpful.
- Completely different kernels (both BSD and Mac), therefore I would skip the "did the kernel ignore my flag?" check. That was a workaround for one very specific Linux kernel bug.
- The `#ifdef O_CLOEXEC` does not really help you with backward compatibility if it is really your aim to be runnable on older OSes. Since this tests on the build machine, kernel on the runtime machine may not understand (hopefully ignore) the numerical value O_CLOEXEC.
Honestly, I would not bother. I would just use open with O_CLOEXEC and be done with it. If someone really really wants to build JDK 20 on ancient MacOS or BSD, then we can add complexity.
Just my 5 cent.
Cheers, Thomas
-------------
PR: https://git.openjdk.org/jdk/pull/9663
More information about the hotspot-runtime-dev
mailing list