Changes to httpd WAS: RE: SMS as Pools Patch

[Sander Striker <st...@apache.org>]

> > Part of the problem is that two of the people working on this don't
> > have commit access to httpd.  David Reid does.  I imagine that Sander
> > and I can do stuff and post it to the new-httpd list.  If the
> > new-httpd list judges it a win, it'd go in.  It isn't impossible for us
> > to get things in, but it just makes it a bit more difficult.  -- justin
>
> Given that I'm trying (despite all the misleading subject lines) to follow
> this, if something needs to go into httpd then I'll commit it once I've
> looked at it.  I actually think most of the issues are within APR and only
> once we've addressed some of those will we really be at the stage
> of making
> changes to httpd...  Using the threads sms will be one place
> where it'll be
> worthwhile checking the effect, and if it's as good as we hope then making
> the change.

Well, this was not what I was getting at.
I meant that it is not, IMHO, advisable to do any changes to the
httpd codebase until we have a stable, proven, sms codebase.
In httpd everything should, for the time being, be transparent.

When, and most importantly, if, sms becomes the default in httpd we
can start ripping out apr_pool_create lines and replace them with
apr_sms_xxx_create calls (where xxx is the most appropiate sms instance
in that part of the application). For clarity: I'm not talking about
namespace now. It could very well be that apr_sms_xxx_create becomes
apr_pool_xxx_create in the future, but that's a different discussion.

The exception is ofcourse putting in some of these in exceptional locations:

#if POOLS_ARE_SMS
     apr_sms_xxx_create(p, parent);
#else
     apr_pool_create(p, parent);
#endif

But this is ofcourse no solution for all the apr_pool_create calls.
There are 39 apr_pool_create calls in httpd (this is excluding the
calls in apr and apr-util, but including all the modules, including
mod_example).

Sander