Date: Sun, 19 Dec 1999 13:39:18 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Ronald F. Guilmette" <rfg@monkeys.com> Cc: hackers@FreeBSD.ORG Subject: Re: Practical limit for number of TCP connections? Message-ID: <199912192139.NAA09232@apollo.backplane.com> References: <47599.945636445@monkeys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:I'd like to just take a second and re-express my growing confusion on
:this whole topic.
:
:Why do you say that this complete-process-blocking effect only takes
:place in the case of disk reads?? Isn't a read a read? What difference
:does it make what the device type being read from is?
:
:Is there some piece of code burried somewhere in either libc or the
:kernel that checks each call to read(2) to find out if that is a disk
:drive you are reading from versus reading from a terminal or a network
:socket?
:
:I'm just trying to understand this stuff.
There are certain I/O related operations which are assumed to not
block, even though the kernel *might* block on the temporarily.
For example, when you open and read() from a file, you assume your
read() command will return reasonably quickly - even though in actual
fact the data may not be cached and the OS may have to read it from
the physical disk, blocking temporarily.
On the otherhand, if you are read()ing from a pipe, keyboard, or a
TCP connection, you assume that the read() will block for (potentially)
long periods of time.
In such cases where you believe the read() or write() might block, you
typically use select() and O_NONBLOCK to tell the system not to block
on the I/O and to tell you when you *can* read or write to it without
blocking.
However, things like disk I/O are assumed to not block, even if they
do for short periods of time, and select() does not work on such those
descriptors.
The reason this is important is the same reason why a program doing lots
of heavy, parallel disk I/O might decide to fork a couple of processes -
because some disk I/O operations can be handled from the cache without
blocking, and others will not be, and it's impossible to know which ones
will and which ones won't. So the reason you fork a couple of processes
in this case is to ensure that if one blocks on a disk I/O, some of the
others can still do read()'s and write()'s through the cache without
waiting for the one blocked on disk I/O to complete first.
If you don't do this then all of your I/O operations will be held up by
the one blocking on disk I/O even if some of the others could be handled
from the disk cache without blocking.
-
The current threads implementation has this problem because you have N
threads running under a single process. If one thread blocks on a disk
I/O then all the threads essentially block. The proposed new
threads implementation does not have this problem.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912192139.NAA09232>