Hello!
> _not_ aborting read() and in absence of the third thread we _do_ abort
> read(). QED: close(dup(fd1)) changes the behaviour of program.
>
> IIRC, you've agreed that it was wrong just a couple of posts upthread.
Read is aborted as soon as file closed. File is closed,
when nobody has access to it. While third thread holds it open,
hothing happens. As soon as all the access points are deleted,
file is closed.
Alive object cannot be orphan. That's invariant to hold.
> Yes? How about close() right _after_ read() returns? Should it
> retroactively change the return value to -EBADF? You have the race
> anyway.
Moreover! If read() has some _data_ read while close() (due to race or
due to SO_RCVLOWAT) it does not return error. It returns data
despite of neither descriptor nor file itself exist to this time.
It is normal.
> Look: you are asking for completely new mechanism for aborting blocked
> IO operations. Occam's Razor applies.
Nope. "New" mechanism already exists, at least for sockets.
It is shutdown(2). But it works only in Linux.
> Arguments against that mechanism:
> * doesn't work unless caller has all references to file at hands
> and remembers about them.
> * doesn't provide anything new compared to kill(2).
> * in the case when read would succeed it introduces a new effect -
> close(dup(fd)) changes the program behaviour.
>
> What are your arguments for the inclusion of this mechanism, aside of the
> fact that Solaris has it?
No ones. Except for ecological ones: I prefer when children
have parents. Orphaned files must be closed.
What a pity, I have already used these your arguments. 8)
Only third one sounds different: not close(dup(fd)) changes
behaviour of program, but close() in thread is poorly defined
and its result is unpredictable, when more than one thread use
this descriptor. So, you (not you, but that poor programmer 8))
are fool, we are all in the white. 8)
The problem is that it is unpredictable in theory.
In practice kernel is able (and does in other unces) predictably
not to lose files and threads and not to hang in sleeps.
> former to Linux. Question: what for?
Do you want really honest answer? Keep it!
Because I am tired to prove that it is not a bug in TCP. 8)
As you can guess, the problem is really essential only for TCP,
because it has to make an active action (FIN) to start close
and because it has another syscalls (connect, accept), which
hang really frequently. And because no OSes provide tools to do this,
so that people learned and use close().
Also, because it is easy to argue to you (and even to Linus 8)),
I know that after some sleep you will calm down, understand my point,
switch to something constructive, and reject or accept it.
But it is impossible to argue to guy, who is porting his (bogus) software
from nt,solaris,dux in hope to make some more money (or PR, if he is more
clever) on linux boom and sees that his app has no chances to work. 8)
If you tell hime about kill(), he will kill you; he learned
MT programming exactly to forget about signals forever. 8)
Alexey
-
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:21 EST