+1 We should have spotted it in the review though.
Cheers, Mario Il 29/ott/2014 21:47 "Christos Zoulas" <[email protected]> ha scritto: > On Oct 29, 1:12pm, [email protected] (Martin Buchholz) wrote: > -- Subject: Losing features of JVM_Open, e.g. CLOEXEC > > | throwing away use of old shared infrastructure and replacing with "naked" > | calls to the OS. Although understandable, this abandons benefits of > using > | shared infrastructure. Here I'm thinking of the close-on-exec flag. I > | just added use of O_CLOEXEC to linux hotspot, but e.g. zip file opening > no > | longer uses JVM_Open, which is a code hygiene regression. > | > | What we want is to have almost all file descriptors have the > close-on-exec > | flag automatically set at fd creation time, using O_CLOEXEC where > | available, and FD_CLOEXEC where not. How do we get there? > | > | I'm distressed that the JDK core libraries should be moving towards > having > | *more* shared native code infrastructure, but here we seem to be moving > in > | the opposite direction. Having abandoned JVM_Open, the responsibility of > | doing these things right belongs entirely to the core libraries team. So > | where's the core-library replacement for JVM_Open? > > I totally agree with Martin here. Changes like this are harmful. > > christos >
