In article <200008271925.XAA18034@ms2.inr.ac.ru>,
<kuznet@ms2.inr.ac.ru> wrote:
>
>User references must be counted separately.
Sorry, Alexey, but you're just wrong.
The behaviour you seem to advocate is stupid.
End of story.
>Actually, Linus seems to forget about his own idea
>of returning valid error from close(). Think, how it is possible
>to return valid error, when fput() is used to close file.
Bzzt. Wrong answer.
My claim is that a user program that does a close() on a file that is in
use is inherently racy. Is that so hard to understand?
I'm basically saying: if you want reliable behaviour, you should make
sure in user land that you don't close a file descriptor that is in use
somewhere else. Linux _will_ give you reliable and dependable semantics
even if you close() on an fd while it is in use, but I still claim that
you should not do it.
EXACTLY because you lose the error information, if for no other reason.
Imagine that another thread is doing a write() on the fd at the same
time as your thread is doing a close(). I claim that that is a stupid
thing to do, and that you shouldn't do it. Linux makes certain that the
kernel is internally consistent, and you might even choose to depend on
that internal consistency, but your program is doing things it shouldn't
be doing.
You'll lose the errors from the operation, for example. Tough. I'm not
"forgetting" anything. I'm claiming that it's a "Don't do that then"
case.
And I'm right. I'm always right, but in this case I'm just a bit more
right than I usually am.
Just don't close a file descriptor while it is in use. It's that simple.
(I'm also claiming that Linux will give the most reasonable possible
semantics for the case where you _do_ close the file desciptor when it
is in use. I still claim that you shouldn't do it.)
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:20 EST