From: "Matthias Urlichs" <smurf@noris.de>
To: Alexander Viro <viro@math.psu.edu>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
thierry.lelegard@canal-plus.fr, linux-kernel@vger.kernel.org
Subject: Re: PROBLEM: I/O system call never returns if file desc is closed in the
Date: Thu, 7 Jun 2001 08:06:27 +0200 [thread overview]
Message-ID: <20010607080626.S21844@noris.de> (raw)
In-Reply-To: <p05100310b744a22f02a6@[192.109.102.42]> <Pine.GSO.4.21.0106070043530.11086-100000@weyl.math.psu.edu>
In-Reply-To: <Pine.GSO.4.21.0106070043530.11086-100000@weyl.math.psu.edu>; from viro@math.psu.edu on Thu, Jun 07, 2001 at 12:56:29AM -0400
Hi,
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/
next prev parent reply other threads:[~2001-06-07 6:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-06 14:26 PROBLEM: I/O system call never returns if file desc is closed in the meantime thierry.lelegard
2001-06-06 21:35 ` PROBLEM: I/O system call never returns if file desc is closed in the Alan Cox
2001-06-07 3:25 ` Matthias Urlichs
2001-06-07 4:24 ` Florian Weimer
2001-06-07 4:43 ` Alexander Viro
2001-06-07 12:25 ` Florian Weimer
2001-06-07 15:33 ` Alexander Viro
2001-06-07 4:56 ` Alexander Viro
2001-06-07 6:06 ` Matthias Urlichs [this message]
2001-06-07 6:14 ` Alexander Viro
2001-06-07 22:14 ` David Schwartz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010607080626.S21844@noris.de \
--to=smurf@noris.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=thierry.lelegard@canal-plus.fr \
--cc=viro@math.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.