Messages in this thread |  | | Date | Mon, 28 Aug 2000 14:51:15 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [PATCH] thread wakeup fix for 2.4.0-test7 |
| |
On Mon, 28 Aug 2000 kuznet@ms2.inr.ac.ru 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 down.
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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |