httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <dgaudet-list-new-ht...@arctic.org>
Subject Re: Moving things around
Date Wed, 10 May 2000 17:31:49 GMT
On Tue, 9 May 2000 rbb@covalent.net wrote:

> Every multi-threaded MPM already does one thread per request.  Having two
> or three different MPM's in the same binary seems like a support
> nightmare, and a bit ludicrous to me.  Why would we want to do
> this?

to quote tony finch, "not everything is linux".

linux:
- a pthread is a kernel schedulable object (a task)
- kernel schedulable objects consume non-swappable kernel resources, and
  have higher cost context-switching requirements
- therefore the fastest MPMs on linux will require a hybrid threading
  library, or async i/o
- it is possible for someone to write an NSPR or pth-based MPM which
  would kick the current MPMs' butt.  the pth one certainly couldn't
  be in our tree due to GPL.

linux again:
- linuxthreads are more expensive than clone()d tasks due to insanities
  required to support lame-ass posix pthread semantics
- someone could write a native linux clone-based MPM which would have
  some pretty specific linking/etc. requirements... but would improve
  performance by virtue of eliminating needless signalling crud

solaris:
- a pthread is a userland schedulable object, multiplexed on top of lwps
- the hybriding is already done for us, and the mpmt_pthread or dexter
  MPMs will probably be about as fast as we can go on solaris without
  going async

irix:
- sprocs are essentially just like clone under linux, yet another speed
  improvement possibility

there's lots more possibilities as you consider more operating systems.

MPM is there so that vendors *can* make an apache kick ass on their
platform, if they choose to do so.  the current situation is that
vendors write a custom webserver because 1.3 couldn't support multiple
processing models.

the problem is that applications (modules) have to be written in ways
that are friendly to each variant.  there's no way you can support all
permutations of modules with all permutations of MPMs.

and nor should you bother trying!

proxying technology is the key (where "proxying" includes things such
as object messaging protocols).

it's stupid to be propagating this "everything inside one process image"
crap that is the current apache mindset.  it's equivalent to putting
everything inside the kernel image just because it can be faster.
faster sure, but reliable?  maintainable?  secure?  fuck no.

KISS.  do one thing, and do it well.  each MPM should do one thing
and do it well -- that alone is an argument for prefork in my opinion.
mpmt_pthread is a multithreaded program and requires you to link with
threads (i certainly don't see <pthread.h> being conditionalized).
linking against pthreads affects every single bit of code compiled with
the program:  if not every library is compiled with -D_REENTRANT then
*IT WON'T WORK*.

therefore, the decision to use a particular MPM has affected the entire
compilation chain.

the standard solution i see here is, "oh, let's just include that
library into our compilation tree then!"  yeah this scales, pretty
soon we'll have the apache distribution on three CDs just because
we include every single library under the sun so we can recompile
it our special way.

gah.

-dean


Mime
View raw message