From owner-freebsd-hackers Sun Dec 19 13:39:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 59357151A6 for ; Sun, 19 Dec 1999 13:39:22 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA09232; Sun, 19 Dec 1999 13:39:18 -0800 (PST) (envelope-from dillon) Date: Sun, 19 Dec 1999 13:39:18 -0800 (PST) From: Matthew Dillon Message-Id: <199912192139.NAA09232@apollo.backplane.com> To: "Ronald F. Guilmette" Cc: hackers@FreeBSD.ORG Subject: Re: Practical limit for number of TCP connections? References: <47599.945636445@monkeys.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message