Losing features of JVM_Open, e.g. CLOEXEC

[Martin Buchholz]

Hi Frederic,

On Thu, Oct 30, 2014 at 10:54 AM, frederic parain
<frederic.parain at oracle.com> wrote:
> My bad. I missed the FD_CLOEXEC flag added by os::open()
> when I replaced JVM_Open with open in zip native code.
>
> However, I still think that removing those interfaces
> was a good move. But I understand that the change it
> introduces with zip file descriptors is an issue.

By itself, it is not so bad - I I've been saying, the overall
situation has been broken since forever.

> Reverting the changeset to re-introduce JVM_Open is
> not a solution. Maintaining a VM interface only adding
> a flag for only 2 call sites doesn't make sense to me.

I agree this should not be a "VM interface", so in that sense your
change is an improvement!
But we still need a common infrastructure/porting layer... and instead
we're working on dismantling any that we have...

> Either the file descriptor leak issue is specific to
> the zip package and can be fixed locally. Or the issue
> impacts more native code and adding an infrastructure
> to libjava should be discussed. Quickly grepping the
> code, I found many naked calls to open, but only one
> use of FD_CLOEXEC. Further investigations would be
> required to track potential file descriptor leaks in
> all libraries.
>
> Did you create a bug to track this issue yet?

Nope.  But if I did, what component/sub-component would it go into.?
We don't even seem to have a place to report cross-library bugs!  We
have no infrastructure to work on the "no infrastructure" problem!