On Mon, 28 Aug 2000 kuznet@ms2.inr.ac.ru wrote:
> > > > Yes? So how about
> > > > fd2 = dup(fd1);
> > > > read(fd1,...);
> > > > close(fd1);
> > So _which_ case should abort read()?
>
> No case. f_users is not zero, nothing happens.
In other words, with three threads we have
read(fd1...) fd2=dup(fd1);
close(fd1);
...
[here read() would succeed]
...
close(fd2);
_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.
> What happens now is race window: if close(fd) happens before
> read(fd) grabbed fd or after it fput() it, we get EBADF,
> otherwise read() hangs forever. (Actually, even absence of invariance
> can be considered as bug.)
Yes? How about close() right _after_ read() returns? Should it
retroactively change the return value to -EBADF? You have the race
anyway.
Look: you are asking for completely new mechanism for aborting blocked
IO operations. Occam's Razor applies.
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?
It's not fixing a bug. Application does blocking operation and then uses a
mechanism that would abort that operation on Solaris. This mechanism
doesn't work on Linux. There is another mechanism that works on both; as
the matter of fact it works on every UNIX. You are asking to add the
former to Linux. Question: what for? It's not a demagogy, I honestly don't
see the rationale for that change. That's my problem with your suggestion
and I would really like to hear the explantion on that point.
-
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