Re: [apache-plusplus] Process model ideas for C++ Apache.

[Dean Gaudet <dgaudet@arctic.org>]

On Tue, 26 May 1998, Bret wrote:

> 	However, am I to understand then that NSPR only provides access to a
> multi-fibered, multi-threaded model whenever pthreads is available?  While
> I agree that SMM is a far more interesting model to work from, this raises
> some concerns in the back of my head...

Nope, it hides everything so that any of SMS, SSM, SMM models can be used
without change to the application -- i.e. it just provides the concept of
"thread" and as long as you use all of its interfaces you don't have to be
aware at all which of the models are in use.  It currently has SMS
implementations where the vendor provides thread libraries (i.e. pthreads,
linuxthreads, or irix sprocs), a fairly portable unix SSM implementation,
and a fairly portable SMM implementation on top of pthreads.  I say
"fairly" because I don't think folks have compiled all the options
everywhere yet, because NSPR's major application right now is Mozilla
which I think needs to use SSM everywhere for arcane reasons; but there's
no deficiency I've seen in the NSPR API that would prevent the use of any
of those models.  It's "just a small matter of coding" to get the various
models up on the platforms we're interested in. 

Mxx naturally requires application awareness, and it's possible as well. 

> 	Ooops... those ACE guys never cease to amaze me.  Looks like Schmidt's
> design is even more robust than NSPR; a cursory glance suggests that you
> can even chose the model you wish to use at run-time.  Wow...

I'm pretty sure we could do this with NSPR as well -- I've been thinking
about how to make the NSPR library choice a dynamically loaded option.  It
looks like it's completely possible.  This is a good thing because there
are issues with interfacing the various models to 3rd party libraries. For
all intents and purposes the SMS model using pthreads is the only model
that will work with all thread-capable 3rd party libraries.  There are
ways to get SMM to work as well.  But SSM is out of the question --
because if the library does any system call it could block the entire
application.

> 	Guess this is the cause of my concern.  I could be reading this wrong, but
> it sounds as if we're coding optimizations which are specific for certain
> platforms, specifically platforms with pthreads.  Will we see a performance
> hit elsewhere and, if so, will it be significant?

No, I'm talking about not coding any optimization into Apache.  I'm saying
the optimization belongs in the OS-abstraction library, in my case that's
NSPR.  And it belongs there specifically because it will be different on
NT, Linux or Solaris for example. 

> 	The other obvious question is, if this is a problem, could we distribute a
> uniform thread implementation somehow?  Okay, so I'm asking for divine
> intervention, but hey, why not? :)

Yup, NSPR :) 

> 	Okay... things are becoming clearer.  Distributing a modified NSPR which
> handles these issues beyond the programmers gaze solves quite a few
> problems.  How much would it take to modify NSPR not just to do this sort
> of book-keeping, but to do it efficiently, all by itself?  It would not
> only be useful for Apache, I'm sure the Netscape folks would be _very_
> excited about it... the idea is very intriguing...

For all the NSPR modifications I've been considering I'm trying to be as
general and clean as possible.  I want netscape to accept the changes back
into their distribution.  There's a couple of the NSPR engineers on
new-httpd now, and they haven't raised many red flags to my babbling yet
:) 

> 	I had assumed that the mutexes were there as a rough attempt at eventually
> moving away from a pre-forked model into something more like a purely
> multithreaded model, but your docs suggest otherwise.  Just out of
> curiousity, is there some reason the Apache group is so devoted to a
> pre-forked model?

No, we're not devoted to it per se.  It has just done a very good job for
the past 4 years.  It certainly isn't the fastest model, but it is by far
the most reliable model -- except for common failure modes (which take out
the entire server in any model), point failures take out a single request
and not the entire server.  So as we move forward we want to keep some
balance between the reliability of multiple processes and the speed of
threading -- which is why MMM, MSM, MMS are "interesting".  Obviously
threading opens up many more opportunities for optimizations and
applications... if it didn't we'd probably just stick with pre-forking.

You can do a lot with a squid accelerating an apache :)

Dean