From: "David Schwartz" <davids@webmaster.com>
To: "Matthias Urlichs" <smurf@noris.de>
Cc: <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 15:14:04 -0700 [thread overview]
Message-ID: <NCBBLIEPOCNJOAEKBEAKMECAPKAA.davids@webmaster.com> (raw)
In-Reply-To: <p05100310b744a22f02a6@[192.109.102.42]>
> At 22:35 +0100 2001-06-06, Alan Cox wrote:
> > > This report describes a problem in the usage of file
> > > descriptors across
> >> multiple threads. When one thread closes a file descriptor, another
> >> thread which waits for an I/O on that file descriptor is not notified
> >> and blocks forever.
> >THe I/O does not block forever, it blocks until completed.
> That's still "forever" if you don't specify a timeout in the select.
If you don't want to block until an operation completes, then don't ask to!
> >The actual final
> >closure of the object occurs when the last operation on it exits
> 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.
That is not quite correct. That is a good approximate definition of
'select's behavior, but it is not exact. As for your assertion that a
noblocking read/write wouldn't block, that's not necessarily true. Remember,
the 'close' may not have taken affect yet, since the descriptor is still in
use by virtue of being selected on.
> A related problem is that the second thread my be inside a blocking
> read() instead of a select() call. It'd never continue. :-(
Perfect. Doing this is absolutely, positively wrong and the more you are
punished for it, the better. It's as wrong as calling 'free' on a chunk of
memory when another thread may be usign it. It is impossible to make this
work safely, as another thread could open a socket or file and get the same
descriptor write before the call to 'read' is entered. There's no possible
way to do this because there is no 'unlock a mutex and read' operation.
> HOWEVER: IMHO it's bad design to distribute the responsibility for
> file descriptors between threads.
Why? That's a great design and it's absolutely essential in many cases.
Suppose, for example, I have two descriptors I want to write to. If I assign
one thread to each socket permanently, then I'm 100% guaranteed a context
switch every time I change which socket I'm writing to, so if there's lots
of small bits of data going out both of them, my performance will suck. But
if I assign one thread to both socket descriptors, I'm guaranteed that one
connection will stall if the the application-level send queue for the other
has been swapped out to disk. Not distributing network I/O across threads
dynamically is a recipe for either low performance or bursty performance.
DS
prev parent reply other threads:[~2001-06-07 22:14 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
2001-06-07 6:14 ` Alexander Viro
2001-06-07 22:14 ` David Schwartz [this message]
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=NCBBLIEPOCNJOAEKBEAKMECAPKAA.davids@webmaster.com \
--to=davids@webmaster.com \
--cc=linux-kernel@vger.kernel.org \
--cc=smurf@noris.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).