Date: Sun, 19 Dec 1999 14:38:28 -0800 From: "Ronald F. Guilmette" <rfg@monkeys.com> To: hackers@FreeBSD.ORG Subject: Re: Practical limit for number of TCP connections? Message-ID: <48477.945643108@monkeys.com> In-Reply-To: Your message of Sun, 19 Dec 1999 13:39:18 -0800. <199912192139.NAA09232@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199912192139.NAA09232@apollo.backplane.com>, Matthew Dillon <dillon@apollo.backplane.com> wrote: >: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... What do you mean by ``you'' in this context? > ... > However, things like disk I/O are assumed to not block... Assumed by what exactly? Thank you for the elaborate answer, but you didn't really address my question. Is there code somewhere, perhaps within the libc implementation of read(2) that looks to see what kind of device I am reading from, and then does two different things if the read is for a disk file versus a read for a terminal? If so, and if that code operates in userland (as opposed to being in the kernel), then to a certain extent that kinda shoots the hell out of the old UNIX transparency notion that ``a file is a file is a file''. I'm not complaining about that mind you. I'm just noting it, and the fact that (for me at least) it makes me just slightly uneasy for reasons I can't quite put into words. > 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. Good. I gather from your other comments that the new threads implementation will indeed return us to a state where ``a file is a file is a file'' and where no special handling of different _kinds_ of files takes place (or needs to take place) within, for example libc read(2). 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?48477.945643108>