Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!howland.reston.ans.net!agate!news.duke.edu!eff!news.umbc.edu!haven.umd.edu!cs.umd.edu!not-for-mail From: torek@elf.bsdi.com (Chris Torek) Newsgroups: comp.unix.bsd.bsdi.misc,comp.unix.advocacy Subject: multiple httpds vs threads vs ... (was BSDI Vs. NT...) Date: 25 Dec 1995 11:04:25 -0800 Organization: Berkeley Software Design, Inc. Lines: 52 Message-ID: <4bmsjp$7lv@elf.bsdi.com> References: <taxfree.3.00C439A1@primenet.com> <4be592$6tb@madeline.ins.cwru.edu> <4bhfmp$gei@Mars.mcs.com> <DK5Crs.I77@metrics.com> Reply-To: torek@bsdi.com NNTP-Posting-Host: elf.bsdi.com Xref: euryale.cc.adfa.oz.au comp.unix.bsd.bsdi.misc:1828 comp.unix.advocacy:12629 In article <4bhfmp$gei@Mars.mcs.com> les@MCS.COM (Leslie Mikesell) notes: >... someone has to demonstrate that there is an advantage for [threaded http servers] In article <DK5Crs.I77@metrics.com> Tom Haapanen <tomh@metrics.com> wrote: >Demonstrate how? The processor overhead of forking, and the memory >overhead of multiple httpd processes are pretty significant. Using >threads can cut this overhead down significantly, regardless of the OS. This is drifting awfully far from BSDI-specific topics, and even fairly far from something appropriate for comp.unix.advocacy, but it may be worth pointing out that there are several philosophies of thought here. One can argue that fork (and separate address spaces) is `too heavyweight' and that one needs lightweight processes sharing an address space, aka `threads', to solve the problem. On the other hand, one can argue that if the problem is that fork is `too heavy', the solution is not to add yet another fundamental object (the thread) to the system, but rather to make fork `lighter'. There is a third approach---in one way, kind of a compromise between these two---and that is to provide a mechanism such as poll() or select() by which a process can implement its own `threading' (except that these threads can be even lighter-weight than kernel threads). It seems almost too obvious for words that, all else being equivalent, threads will be lighter-weight than processes, since a process is simply a thread with an address space, and changing address spaces has to have some cost. The cost is machine-dependent; it is usually moderate but never zero. On the other hand, if the threads provided are preemptive, a program that makes use of them must also use synchronization to be reliable. This synchronization has a cost as well, and it is easy to believe that this will rapidly eat away any savings from staying in a single address space. (I leave the argument about the difficulty of getting such synchronization correct for another argument entirely, but would like to suggest that this is [part of] why operating systems were invented.) That leaves non-preemptive threads, but for the most part, these can be implemented on top of select() or poll(). As for http itself, I will simply note that Jef Poskanzer has been working on something called `thttpd' that implements threaded HTTP service in a single UNIX process using select(). My understanding is that, while it is not (yet?) as `full featured' as other existing HTTP servers, it beats the pants off them. -- In-Real-Life: Chris Torek, Berkeley Software Design Inc El Cerrito, CA Domain: torek@bsdi.com +1 510 234 3167