Re: [patch 7/7] uml: retry host close() on EINTR

[Linus Torvalds]

On Sun, 11 Sep 2005, Paolo Ornati wrote:
> 
> So glibc doc is wrong here:

Yes.

> SUSV3:
> -------------------------------------------------------------
> If close() is interrupted by a signal that is to be caught, it shall
> return -1 with errno set to [EINTR] and the state of fildes is
> unspecified
> -------------------------------------------------------------
> 
> Unspecified! ;-)

I don't know of any system where re-trying the close() is the right thing
to do, but I guess they exist. I think the Linux behaviour of "hey, it's
closed, live with it" is pretty universal - almost nobody ever tests the
return value of close().

Even the "careful" users that want to hear about IO errors have to really 
do an fsync(), so any IO errors should show up there. Of course, checking 
the return value of "close()" in addition to the fsync() is always a good 
idea anyway, and I suspect they do.

In Linux, another thread may return with the same fd in open() even _long_
before the close() that released it has even finished. The kernel releases
the fd itself early, and then the rest (anything that could return EINTR -
things like TCP linger stuff etc) is all done with just the "struct file".

So retrying is really really wrong. And not just on Linux. I think this is 
true on _most_  if not all unix implementations out there.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/