On 5/18/20 11:11 AM, Alan Bateman wrote:
On 18/05/2020 09:59, Peter Levart wrote:
:
Please elaborate. Do you have an example of such use case? Are there
any existing races possible?
Everywhere that closes a file descriptor needs to coordinate the
closing with threads that may be accessing that file descriptor,
otherwise you risk doing I/O on file descriptors that have been
recycled. This has always been problematic for the legacy java.io
classes, so the concern is that increasing the window where you are
using the "raw" file descriptor will make it worse.
-Alan.
Ah, that. So the concern is that the operation performed would be
performed on the wrong file because the fd/handle would be recycled. So
here you assume that transition from java to native code takes
considerably more time than the part of GetIntField JNI API call between
reading the field value and completing the call? Or is the transition to
native code equipped with some sort of implicit memory barrier so that
reading the filed from native code makes it more recent? If that last is
the case then perhaps such memory barrier could be issued in java code
too...
Regards, Peter
