From owner-freebsd-hackers Sat Dec 18 14:57:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 5A45B14D7D for ; Sat, 18 Dec 1999 14:57:23 -0800 (PST) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) with ESMTP id PAA12420; Sat, 18 Dec 1999 15:28:33 -0800 (PST) Date: Sat, 18 Dec 1999 15:28:33 -0800 (PST) From: Alfred Perlstein To: Kevin Day Cc: "Ronald F. Guilmette" , hackers@FreeBSD.ORG Subject: Re: Practical limit for number of TCP connections? In-Reply-To: <199912182058.OAA42531@celery.dragondata.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 18 Dec 1999, Kevin Day wrote: > > The _clean_ way of doing it would be to write your multi-user server using > > threads, and to assign one thread to each connection. If you can do that, > > then the logic in the program becomes quite simple. Each thread just sits > > there, blocked on a call to read(), until something comes in, and then it > > just parses the command, does whatever it is supposed to do in response to > > that command, and then goes back to the read() again. > > > > But as I understand it, there is not yet sufficient threads support in the > > FreeBSD kernel to make this work well/properly. (I may perhaps be misinformed > > about that, but that's what I have been told anyway.) > > I believe this is how ConferenceRoom works, so it seems ok, but I remember > the comments that FreeBSD was their least preferred platform because of > thread problems. Using a thread per connection has always been a bogus way of programming, it's easy, but it doesn't work very well. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message