RFR [8055421]: (fs) bad error handling in java.base/unix/native/libnio/fs/UnixNativeDispatcher.c

Alan Bateman Alan.Bateman at oracle.com
Sun Aug 24 13:13:28 UTC 2014

On 22/08/2014 21:59, Ivan Gerasimov wrote:
> How about another approach?
> If we face EINTR, we can try to fallback to restartable close():
I was away for a few days and just catching up on this thread now.

I agree with Florian's original comment as there is something fishy 
about the original bug report and it would be useful to know if there is 
really a case where we are calling this native method with errno set. In 
any case, the long standing rule with close is that you never retry it 
after EINTR because the behavior is undefined. It's an oversight in the 
original implementation to have used a restart loop in fclose and to 
have used the RESTARTABLE macro in closedir. Apologies about those. The 
proposed change to dup looks okay, that would be a problem if dup were 
called when there aren't any file descriptors available.

On fclose then one thing to note is that it is only used on Solaris when 
reading /etc/mnttab, I don't think it is used elsewhere. So write 
buffering isn't an issue with the current usage. If there was writing 
then Martin's suggestion to use a restartable fflush would be good to 
do. It also means that having fclose ignore EINTR as per your 1/webrev 
is okay too. For completeness then we could add a new method fflush 
method that might get used someday.

For closedir then dropping the use of RESTARTABLE and ignoring EINTR 
should be okay.


More information about the nio-dev mailing list