fopen vs. os::fopen and automatic closing of the file on exec

[Leo Korinth]

On 29/01/2020 14:03, Baesken, Matthias wrote:
> Hi  Leo / Thomas / David,
> 
>   Not sure if it is a small  or “medium” gain ,  but after the 
> discussion so far I think it makes sense to use  os::fopen in HS code  
> where possible
> 
>   (  what (f)open does in the  jdk C coding is a different thing, we 
> might dicuss this on corelibs-dev  in more detail ).
> 
> I opened
> 
> https://bugs.openjdk.java.net/browse/JDK-8238161

I linked your bug to https://bugs.openjdk.java.net/browse/JDK-8202720 
(process) Clarify file handler behaviour

I have no idea why we (explicitly) keeps files open on Windows on exec, 
I think maybe that issue should be dealt with first as it might affect 
this proposed change.

Thanks,
Leo

> 
> use os::fopen in HS code where possible
> 
> Best regards, Matthias
> 
> Hi Leo,
> 
> On Tue, Jan 28, 2020 at 4:37 PM Leo Korinth <leo.korinth at oracle.com 
> <mailto:leo.korinth at oracle.com>> wrote:
> 
> ...
> 
>     Something that is not obvious is that on unix-like operating systems,
>     ProcessImpl_md.c tries to close (most) open files between fork and
>     exec.
>     That is not the case for Windows (I opened
>     https://bugs.openjdk.java.net/browse/JDK-8202720 for this). Thus (if I
>     understand correctly) the impact on unix-like operating systems will be
>     less for adding this support than it is for Windows. os::fopen was
>     created to solve a specific bug on windows (logging), and was
>     renamed to
>     the more generic os::fopen during review.
> 
> Just a note, it is still possible for file descriptors to escape into 
> child processes since you cannot guarantee that all forks happen via 
> Runtime.exec():
> 
> - native third party code may fork.
> 
> - hotspot may fork to run tools for error reporting
> 
> Also note that the code which closes fds in Runtime.exec() may in theory 
> fail to close all fds.
> 
> So I think Matthias makes sense on Posix platforms.
> 
>     I guess most uses of ::fopen /should/ use the more restricted
>     os::fopen,
>     but the gain would probably be small.
> 
>     Thanks,
>     Leo
>