You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by David Robinson <dr...@ast.cam.ac.uk> on 1995/07/12 20:19:00 UTC

Threads (was Re: Shambhala Modules Musings...)

>From: rst@ai.mit.edu (Robert S. Thau)
>Date: Mon, 3 Jul 95 15:50:00 EDT
>
>   From: Rob Hartill <ha...@ooo.lanl.gov>
>   Date: Mon, 3 Jul 95 11:34:33 MDT
>
>   > Ah, but one of my not-so-hidden agendas here is that I'm looking
>   > towards multithreading the thing (I'm not sure how it's possible to
>   > write a decent HTTP-NG server which *isn't* multithreaded, unless you
>   > turn the entire thing into a gigantic collage of state machines, which
>   > generally results in an unreadable mess).  That doesn't give you the
>   > option of tossing the entire address space any time a timeout on one
>   > of the twenty-odd requests it might be serving gets aborted; you need
>   > to find another way out of it.
>
>   Sounds good. Will a threads based system be portable ?, I'm thinking
>   of problems like Rob McCool pointed out, were a Solaris (I beleive)
>   library was leaking, and hence forced the MaxRequestPerChild approach.
>   Perhaps these issues are unrelatated, I know nothing about threads.
>
>The irony here is that Solaris has one of the few kernels which has
>decent native threads support.  To answer the question:  yes, when
>you've got leaky C libraries, you have to rotate server processes
>*eventually*...
>
>What's more of a concern is the portability of the threading interface
>itself.  I know there are some PD threads libraries which are at least
>*supposed* to be moderately portable, but I admit that I need to
>investigate the matter further.

The PD libraries are entirely user-level threads libraries. They simply
provide a a simpler programming solution than the alternative of a large
select() state-machine loop.

The real gain in a threaded server is when you use a library that is built
on top of kernel lightweight processes. You get multiple threads of
execution within a process each of which may be blocked in a system call.
On an MP-machine, your web server could be servicing two requests truly
simultaneously.

The advantage of a multiple-threaded server over a single-threaded,
multiple-process server is one of efficiency and response time, due to
the reduced number of context switches.

I've used the the Solaris threads library intensively, and have not noticed
any major leaks (but have not been looking). OSF/1^H^H^H^H^HDigital UNIX
also has a threads library which seems to be a subset of the Solaris one,
but with all the routines renamed. (As usual.)

  David.