Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code
martinrb at google.com
Fri Feb 1 17:45:24 UTC 2013
Yes, the current Process code deals fairly well with other people's file
descriptors that are not close-on-exec. But this code is brittle, and
long-term it would be cleaner for all open's in the jdk to use O_CLOEXEC by
default. We can probably never remove the Process code that closes all
file descriptors, because native user code could also create file
descriptors. In the near term, until all the posixoid systems we (might)
run on support O_CLOEXEC, it seems better to leave this code as is. Or for
general cleanliness, add O_CLOEXEC by reflex whenever opening a file,
without expectation that users will ever see the benefit, unless they roll
their own fork-exec.
On Fri, Feb 1, 2013 at 1:51 AM, Alan Bateman <Alan.Bateman at oracle.com>wrote:
> On 01/02/2013 02:23, Martin Buchholz wrote:
>> You could operate in paranoid mode and do *both* : use O_CLOEXEC and use
>> fcntl to set the bit after creating it, perhaps after verifying via fcntl
>> whether the bit was successfully set by open.
>> Alternatively, just leave this code out. We open sockets and files in
> many other places in the libraries and don't explicitly enable the
> close-on-exec flag (we do set the inheritance flag on Windows so I guess we
> do have an inconsistency). Anyway, my point is that the Process code
> already handles this and closes the file descriptors in the child so I
> assume it doesn't matter if we have enabled the close-on-exec flag or not.
> There might of course be applications or other libraries that use fork+exec
> or variants directly, in which case there will be an issue if they expect
> all file descriptors to have the close-on-exec flag set. However, I assume
> we have this issue already as we just enable it consistently.
More information about the core-libs-dev