On Fri, Feb 1, 2013 at 9:51 AM, Alan Bateman <alan.bate...@oracle.com>wrote:
> There are lots of places in the JDK that open files or sockets, java.iois > just one. It may be better if we separate this from Dan's clean-up and > decide (as part of a separate piece of work) whether we want everywhere to > enable close-on-exec on its file descriptors or just leave it to > Process.exec as we do now. > My comments are all very high level. The history of generic C-level infrastructure in the JDK is unsuccessful. The JVM_ functions were apparently a failure, but who is willing to own the problem of a suitable replacement? Leaving the problem up to individual component teams is a recipe for each component having different interesting bugs using the same functionality. The obvious examples are: all internal file operations in the JDK should be using LARGEFILE variants on 32-bit platforms. And all file descriptor creations should be using O_CLOEXEC by default (much less important). Does anyone own this problem?