Date: Sun, 19 Dec 1999 12:47:25 -0800 From: "Ronald F. Guilmette" <rfg@monkeys.com> To: hackers@FreeBSD.ORG Subject: Re: Practical limit for number of TCP connections? Message-ID: <47599.945636445@monkeys.com> In-Reply-To: Your message of Sun, 19 Dec 1999 09:22:17 -0800. <199912191722.JAA28697@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199912191722.JAA28697@vashon.polstra.com>, John Polstra <jdp@polstra.com> wrote: >In article <385CEE25.5239137E@newsguy.com>, Daniel C. Sobral ><dcs@newsguy.com> wrote: > >> "Ronald F. Guilmette" wrote: >> >> > As I say, my understanding is that FreeBSD still doesn't have real >> > and/or complete thread support in the kernel. So if you have a >> > multi-threaded application and one thread blocks (e.g. on I/O) >> > then the whole thing is blocked. > >[...] > >> Not to dismiss FreeBSD's kernel problems, but that thing about >> blocking is absurdly untrue. > >It is in fact partially true. If a thread blocks on disk I/O then >the whole process (all threads) blocks... 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. 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?47599.945636445>