From owner-freebsd-hackers Sun Dec 19 14:49:28 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 6271B1515C for ; Sun, 19 Dec 1999 14:49:26 -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 OAA48574 for ; Sun, 19 Dec 1999 14:49:26 -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 16:06:45 -0600. <19991219160645.E317@tar.com> Date: Sun, 19 Dec 1999 14:49:26 -0800 Message-ID: <48572.945643766@monkeys.com> From: "Ronald F. Guilmette" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19991219160645.E317@tar.com>, "Richard Seaman, Jr." wrote: >On Sun, Dec 19, 1999 at 01:21:15PM -0800, Ronald F. Guilmette wrote: > >> 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? > >poll(). It used to use select(). And, not only at each thread >context switch, but each time it has to consider whether to >do a switch at all (eg. at the end of a timeslice). Bummer. I dunno if it goes without saying or not, but this certainly makes the current FreeBSD threads implementation highly unpalatable, except to support ported code which has been developed elsewhere and which is already written to assume the presence/availability of thread library primitives. Certainly, if I were starting out to write a brand new new multi-threaded application program specifically for execution on FreeBSD _today_, I'd either (a) wait for the new thread implementation to be ready or else (b) not use threads at all. (Actually, I guess there is a third option, i.e. writing my code to use the existing threads API, and then just hoping that the new threads implementation shows up before I was done coding my application.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message