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.bate...@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. >> >> Martin >> >> >> 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. > > -Alan. >
