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

[Martin Buchholz]

I worry more about the integrity of the output file than about the file
descriptor.
The big risk is that there is remaining buffered output that would be
written using fflush, the attempt to write the buffered output fails with
EINTR, and the resulting file is missing its last few bytes.

In the real world, fclose probably doesn't encounter EINTR very often.  If
this was a real-world problem, I'd expect it to be a well known piece of
Unix folklore.


On Fri, Aug 22, 2014 at 1:59 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com>
wrote:

> How about another approach?
> If we face EINTR, we can try to fallback to restartable close():
>
> Java_sun_nio_fs_UnixNativeDispatcher_fclose(JNIEnv* env, jclass this,
> jlong stream)
> {
>     int res, fd;
>     FILE* fp = jlong_to_ptr(stream);
>
>     fd = fileno(fp);
>     res = fclose(fp);
>     if (res == EOF) {
>         if (errno == EINTR) {
>             if (fd == -1) {
>                 errno = EBADF;
>             } else {
>                 RESTARTABLE(close(fd), res);
>             }
>         }
>         if (res != 0) {
>             throwUnixException(env, errno);
>         }
>     }
> }
>
> It's strange we have to do this, though.
> I'm pretty sure it was not meant to be used this way.
> I would think that fclose handles EINTR internally, but the documentation
> says nothing about it.
>
> Sincerely yours,
> Ivan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20140822/98e8a5ca/attachment.html>