Why I think we need a SPMT model was Re: [PATCH] Problems with MPM threaded

[Justin Erenkrantz <je...@ebuilt.com>]

On Wed, Jul 18, 2001 at 02:53:33PM -0400, Benjamin W. Ritcey wrote:
> As an end-user of apache, I'd like to chime in: please, please, please leave
> the N processes with M threads model available -- "the hypothetical buggy
> 3rd party modules should be fixed rather than hacked around" is fine in
> theory, but in practice I'd rather have an Apache that can soldier on
> regardless of the crappy modules it's forced to run.  Tuxedo has used the N
> x M model for a long time with good results for similar reasons.

Let me just say that the entire point of the MPM system is to let the
admin choose which model they wish to run under.  I think there is a
place for the multi-process/multi-thread (mpmt) model.

I do think that a single-process/multiple-thread (spmt) model will be 
able to show us a lot of the scalability problems inherent in our 
code and in the overall system.  I agree with Dean that we should try
and expose problems where they exist rather than covering them up
by blindly using a mpmt model.

My personal take on it is that the spmt model is easier to code.  The 
mpmt code currently in Apache 2.0 is quite complicated.  This 
complexity in the code prevents people from analyzing the code and 
getting it to work properly.  The mpmt MPM in Apache 2.0 needs a lot 
more work/analysis before it is of the quality/robustness of the 
prefork MPM.  Please remember that we have a lot of experience doing a
prefork-style model for many years.  The threading MPM is still
relatively new to us and our code.

I think it might be a good exercise on the development side to prove
that a spmt is solid and then move on to a mpmt MPM.  Doing a mpmt 
after a solid spmt model is proven is a lot easier (IMHO) than
jumping straight to the mpmt model without knowing that the spmt model 
even works.  The mpmt MPM implicitly relies on the fact that a spmt 
works well.

And, yes, I do plan on writing a spmt MPM.  But, first we need SMS 
bug-free and the APR thread API needs some tweaks.  A patch has been
submitted for the latter and we need more exposure with the SMS code.
It's time to stop squabbling about design and lead with the code.  =)
-- justin