Losing features of JVM_Open, e.g. CLOEXEC
neugens.limasoftware at gmail.com
Thu Oct 30 10:16:26 UTC 2014
This is exactly what I was about to reply. One can only spot those
things if there is a standardised API, and even in this case it's not
at all easy. That doesn't stop from trying :) but removing the API was
likely a mistake, which would not be a terrible one because of what
David points, except the fact that it's invalidating a fix (at least
this is what I understood from Martin's original mail).
On a related note, some time ago there was a process of standardising
and documenting the VM abstraction (Andrew Hughes was doing that),
does anybody knows what's the state of that? Afaik there's a lot of
infrastructure in place, but it seems more like "we have it more or
less when it makes sense" rather than a carefully planned long term
project. But I think it may be worth expanding over this rather than
This would benefit external VM implementation, which is a good thing,
but the main goal for me would be to have a clearly documented and
logical API with the overall benefit that if we abstract those things
out, we have one single place where bugs can possible be [fixed].
What do you think?
2014-10-30 10:45 GMT+01:00 David Holmes <david.holmes at oracle.com>:
> On 30/10/2014 6:46 PM, Alan Bateman wrote:
>> On 29/10/2014 21:15, Mario Torre wrote:
>>> We should have spotted it in the review though.
>> We should but the ultimate rat catcher should be the tests, it's
>> possible that we have a hole there.
> Not sure how the presence or absence of CLOEXEC would be visible to any test
> - especially given all the other uses of raw open in the JDK sources.
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF
Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
Please, support open standards:
More information about the core-libs-dev