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

[Martin Buchholz]

Looking again at the proposed change, we have an opportunity to actually
change UnixNativeDispatcher_fclose to use my strategy of
RESTARTABLE(fflush) followed by non-RESTARTABLE fclose.  Is that crazy, or
a good idea?


On Fri, Aug 22, 2014 at 12:14 PM, Martin Buchholz <martinrb at google.com>
wrote:

> 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/84ebbedf/attachment.html>