From owner-freebsd-hackers Sun Dec 19 12:40:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from monkeys.com (i180.value.net [206.14.136.180]) by hub.freebsd.org (Postfix) with ESMTP id 8C09D14A1E for ; Sun, 19 Dec 1999 12:40:11 -0800 (PST) (envelope-from rfg@monkeys.com) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.9.3/8.9.3) with ESMTP id MAA47487 for ; Sun, 19 Dec 1999 12:40:10 -0800 (PST) To: hackers@FreeBSD.ORG Subject: Re: Practical limit for number of TCP connections? In-reply-to: Your message of Sun, 19 Dec 1999 23:39:33 +0900. <385CEE25.5239137E@newsguy.com> Date: Sun, 19 Dec 1999 12:40:09 -0800 Message-ID: <47485.945636009@monkeys.com> From: "Ronald F. Guilmette" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <385CEE25.5239137E@newsguy.com>, "Daniel C. Sobral" 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. > >Ouch! That's just not true. > >FreeBSD has userland threads. This is faster than kernel threads, but >has two disadvantages. First, it doesn't make use of SMP. Second, they >all compete together as a single process for CPU time. It seems some >programmers prefer to use threads to increase their process' CPU time >than lowering the process' priority. Well, my apologies for mis-speaking. When I say ``real/complete threads support'', I usually mean threads that: o will in fact get distributed across multiple processors in an a multiprocessor system (if the kernel support multi-processors at all that is), and threads that... o will in fact compete against all other threads/processes in the system for CPU slices, and threads that... o can block on I/O while other threads in the same process continue to be scheduled. Now you are saying that at present, the FreeBSD implementation of threads has at least the last of these three attributes. That's the first _I've_ heard of that, but it is certainly encouraging, and it may cause me to start doing some stuff with threads under FreeBSD. I would really be very grateful however if _someone_ would explain to me the actual low level-mechanics of how this works, i.e. how one thread in a ``multi-userland-thread'' process can manage to get control and/or a CPU time slice when and if a different thread within the same process gets blocked awaiting some I/O completion. For example, take the simplest possible case.... I have a process that is running two threads. One of those threads issues a call to read(2) to read characters from some interactive device... like a terminal. But no characters are yet available. So that thread blocks on the I/O request. In this simple scenario, how does the other thread (which is part of this same process) get control back? Give the other assertions that you've made about threads, i.e. that (in recent releases of FreeBSD at least) they DO NOT compete with each other and/or with other processes on a system-wide basis, I really have a little trouble understanding how the second thread in the scenario I described would manage to get control back. The kernel doesn't even know that that second thread exists as a separately schedualable entity, right? So who (or what) exactly is going to schedule it for execution when the first thread becomes blocked on I/O? >Not to dismiss FreeBSD's kernel problems, but that thing about blocking >is absurdly untrue. I'll take your word for it. I juts wish that I could understand how that could be the case. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message