> > 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