Alexander Viro:
> > Select is defined as to return, with the appropriate bit set, if/when
> > a nonblocking read/write on the file descriptor won't block. You'd
> > get EBADF in this case, therefore causing the select to return would
> > be a Good Thing.
>
> Bzzert. Wrong. It may easily block. open() from another thread might
> grab that descriptor just fine.
>
Sorry, s/file descriptor/file-or-socket-or-whatever.
Actually trying to read from this descriptor is of course a Bad Thing, but
that just means that the programmer forgot to record the file closing in
the program's global state.
> > A related problem is that the second thread my be inside a blocking
> > read() instead of a select() call. It'd never continue. :-(
>
> Yes. So close() doesn't abort read(). Why would it?
>
Well, if it triggers a return from select(), which it currently doesn't
do under Linux, then it should also trigger a return from read() (with
either zero or -EBADF).
I wonder whether any other Unixes do that..?
> Operations like read, select, etc. act of files. Not on descriptors.
>
Right -- I sort-of implied that. My fault.
-- Matthias Urlichs | noris network AG | http://smurf.noris.de/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/