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

On Mon, 28 Aug 2000 wrote:

> 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,

read() may succeed _before_ you close the dup()'d descriptor. You are
thinking about the case when the thing is never going to receive anything
_and_ kernel has no way to recognize that, right? (otherwise kernel should
just return 0 and be done with that). Now, look at the case where read()
_will_ eventually succeed (since we are in "no way to tell" area, we can't
exclude all these cases, right?) Look at the scenario above for that case.
You've got close(dup()) racing with read() and close(); in some cases you
get -EBADF, in some - data. And that race is going to be a hell to hunt

Yes, programs may need a way to abort blocked IO. But overloading close()
is a *very* bad idea.

> 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.

See above.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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