From owner-freebsd-hackers Sun Dec 19 13:21:19 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 5269A14ED7 for ; Sun, 19 Dec 1999 13:21:16 -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 NAA47933 for ; Sun, 19 Dec 1999 13:21:15 -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 14:58:21 -0600. <19991219145821.D317@tar.com> Date: Sun, 19 Dec 1999 13:21:15 -0800 Message-ID: <47931.945638475@monkeys.com> From: "Ronald F. Guilmette" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19991219145821.D317@tar.com>, "Richard Seaman, Jr." wrote: >> 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. > >It would be easier for you to read the code (see libc_r/uthread). >Its very messy. Basically, all i/o syscalls that can block are >converted to non-blocking. If the syscall would block, the userland >thread scheduler handles the "blocking", by scheduling another thread, >and then periodically polling the i/o device to see if its ready. OK. That is a clear and adequate explanation. Thank you. I'm not at all sure that I like the idea of something intercepting my syscalls and rewriting them for me, but I understand why it is being done, and (now) I understand how the current ``userland threads'' stuff works. >This is why the userland thread scheduler is not >very swift, and why user thread context switches are a lot slower >than kernel thread context switches. Yes. It sounds to me like each and every time there is a thread context switch, some code in the library may have to execute a (perhaps enormous) call to select() or else to poll(). Yes? (Please don't tell me this is all implemented with asynchronous I/O completion signals. Yecch. That would be awfully slow I think.) >Also note that you can try kernel threads using ports/devel/linuxthreads. I'm in no big hurry. I'll wait for the freebsdthreads. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message