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

[Martin Buchholz]

Ivan,

Thanks - your arguments are convincing.

It may be that fclose is fundamentally broken in the presence of EINTR!?

It may be that a more reliable way to do "logical fclose" is to do a
RESTARTABLE(fflush) followed by the real fclose.  In this way we'll never
end up with an unfinished flushing write due to EINTR.

http://dreamsongs.com/worseisbetter.html





On Thu, Aug 21, 2014 at 10:35 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com>
wrote:

> On 22.08.2014 3:30, Martin Buchholz wrote:
>
>> Ivan, I think your change for fclose is incorrect, you are discarding the
>> handling for errno = EINTR.
>> I don't think any man page could be serious about not calling fclose
>> again if it returned with errno = EINTR!
>>
>>  I've checked man pages on Linux, Solaris and MacOS and they all seem to
> be consistent:
>
> Linux: Upon successful completion 0 is returned.  Otherwise, EOF is
> returned and the global variable errno is set to indicate the error.
> In either case any further access (including another call to fclose()) to
> the stream results in undefined behavior.
>
> Solaris: After the call to fclose(), any use of stream  causes undefined
> behavior.
>
> MacOSX: Upon successful completion 0 is returned.  Otherwise, EOF is
> returned and the global variable errno is set to indicate the error.
> In either case no further access to the stream is possible.
>
>
> I've also checked some of the implementations available around:
> [1] https://github.com/lattera/glibc/blob/master/libio/iofclose.c
> [2] http://www.opensource.apple.com/source/Libc/Libc-167/
> stdio.subproj/fclose.c
> [3] https://code.google.com/p/android-source-browsing/
> source/browse/libc/upstream-freebsd/lib/libc/stdio/fclose.
> c?repo=platform--bionic&r=6b05c8e28017518fae04a3a601d0d245916561d2
>
> In these the internal buffer is freed no matter what the result of close()
> was.
> Repeated call to fclose upon a failure doesn't seem to hurt, but should
> not be needed.
>
> Sincerely yours,
> Ivan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20140822/6f2c3f4b/attachment.html>