From owner-freebsd-arch@FreeBSD.ORG Wed Mar 26 23:43:55 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7756937B404 for ; Wed, 26 Mar 2003 23:43:55 -0800 (PST) Received: from cirb503493.alcatel.com.au (c18609.belrs1.nsw.optusnet.com.au [210.49.80.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37BBA43F85 for ; Wed, 26 Mar 2003 23:43:54 -0800 (PST) (envelope-from peterjeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])h2R7hEM2019016; Thu, 27 Mar 2003 18:43:15 +1100 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.8/8.12.8/Submit) id h2R7hBXb019015; Thu, 27 Mar 2003 18:43:11 +1100 (EST) Date: Thu, 27 Mar 2003 18:43:11 +1100 From: Peter Jeremy To: Jeff Roberson Message-ID: <20030327074311.GB18940@cirb503493.alcatel.com.au> References: <20030326031245.O64602-100000@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Status: No, hits=-30.9 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: arch@freebsd.org cc: kse@elischer.org cc: Julian Elischer Subject: Re: 1:1 Threading implementation. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2003 07:43:58 -0000 On Wed, Mar 26, 2003 at 12:30:52PM -0800, Julian Elischer wrote: >On Wed, 26 Mar 2003, Jeff Roberson wrote: >> First, if your application has more threads than cpus it is written >> incorrectly. > >Not neccesarily. that's just one way of looking at threads. Active >component threaded programs use threads as a programming model >(see above) and it is a perfectly valid way of writing a program. I'd go so far as to say that the only case where relating real CPUs and threads matters is for compute-bound processes where the only purpose of threading is to get >100% CPU. If you consider an arbitrary server/daemon process, there are a limited number of basic mechanisms you can use to handle more than one client: 1) One (single-threaded) process per client (eg telnetd, sshd) 2) One process with one thread per client (possibly per direction) 3) One process explicitly using select()[*] to support multiple clients. Each approach has its own advantages and disadvantages and each approach requires different support code to handle new clients and switching between clients. Obviously, you can combine the approaches but this means you have the support infrastructure for both basic mechanisms as well as additional code to decide which mechanism to use. Apache is a combination of 1 and 3 - but needs a process dedicated to distributing incoming requests. In general, if you're going to go the effort of threading your server, why go to the additional effort of adding a select() handler in each thread? The big advantage of 1 and 2 is that the core is very simple: while (!eof(input)) { read input do some processing write output } whereas the core of 3 requires building and testing FD sets and making sure that you only block in the select(). This generally makes the code far less clear. You can also potentially reduce the overall throughput because there are multiple scheduling layers. [*] For "select()", read "select() or poll() or kqueue()" Peter