All of lore.kernel.org
 help / color / mirror / Atom feed
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/

  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.