lkml.org 
[lkml]   [2000]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] thread wakeup fix for 2.4.0-test7


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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.098 / U:0.412 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site