httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <>
Subject RE: mod_dav overhaul
Date Thu, 29 May 2003 22:39:01 GMT
> From: William A. Rowe, Jr. []
> Sent: Wednesday, May 28, 2003 9:15 PM

> At 01:12 PM 5/28/2003, you wrote:

> Comments inline, but kudos for taking this on...
>>1. revamp mod_dav's use of pools internally.
>>   This means adding pool arguments to the various "layers" of
>>   function calls within mod_dav.  Each caller controls subpool
>>   creation, and possibly passes a subpool into a subordinate function
>>   call.  Whereever there are loops that allocate temporary memory, we
>>   use (and *clear*) a subpool within the loop.  These changes are
>>   made up to the point of the provider backend;  but we halt there,
>>   and do not pass pools into provider callbacks.
> It makes me wonder... today we have to create and destroy the pool.
> But what about reuse?  The overhead of creating the pool itself?  It seems
> like a good extention to the apr_pool api if we had an apr_pool_recycle
> function that would do the usual pool cleanups and frees, but let us reuse 
> the pool's own memory without getting tangled in thread locking.  For any
> symmetrical use of pools (where each recycle is generally similar in footprint
> to the prior allocations) this could be pretty sweet.

Urgs.  I hope you're not serious.  That would be a special case of
apr_pool_clear, which, instead of giving back all blocks of mem it holds
to the allocator, sits on it itself.

In another reply apr_pool_clear is mentioned.  apr_pool_clear doesn't do what
you suggest.  But, it comes very close when you have thread specific mutex-less
> Just food for thought.

I don't think it is worth it.  It will make the pools code more complex.
It is already fairly complex.  A lot more than I anticipated at first.

>>2. make all mod_dav_svn callbacks take pools.  But then we wrap these
>>   callbacks with wrappers that *don't* take pools, so mod_dav_svn can
>>   still plug-in to mod_dav.
> Why - in the sense that httpd-2.1 forward breaks binary compatibility?
> Wouldn't it make more sense to extend mod_dav_svn (and other dav
> backends) going forward?  We aren't troubling ourselves with that sort
> of compatibility for httpd-2.2, in that we will just get the API 'right' as
> of each major/minor bump.  That means code must be 'adjusted' for
> the next release anyways.

Subversion depends on 2.0.  The 2.0 requirement was hard to sell in the
early days of Subversion.   Fortunately 2.0 is in multiple distributions
already.  A dependency on 2.x would put us back at square one, where 2.x
needs to be 'sold' again.
>>3. use the API versioning which is present in httpd-2.0 (and later) to
>>   define two back-end interfaces for mod_dav. The current interface
>>   is v1, and the new "pool accepting" interface becomes v2.  mod_dav
>>   is updated so that it can use either interface.  mod_dav_svn is
>>   updated to supply both: the old wrapper-based form, and the new
>>   form. This will allow a mix/match between httpd-2.0.X (and 2.X.Y)
>>   and mod_dav_svn.
> I'm mostly asking, is this a real win?

If we don't want to break the existing dav providers out there, then yes,
it is.  There are three providers that I know off from the top of my head,
for more I need help: mod_dav_fs (httpd bundled), mod_dav_svn (subversion)
and mod_dav_dbms (catacomb).  But surely there are more in the commercial
>>4. we can eventually backport these changes from httpd-2.1 to the
>>   httpd-2.0 branch;  it still maintains compatibility with v1
>>   providers, such as mod_dav_fs.
> If we care to.  OTOH, by the time various refactorings are done sometime
> in the late summer or early autumn, it will be time for httpd-2.2 and our
> beloved httpd-2.0 will be in maintenance mode.  Unlike the 1.3 -> 2.0
> move, we don't expect oodles of new instability.
> One more thought for your plate; we can start pulling off httpd-2.1 alpha
> developer tarballs anytime someone shouts 'I'll RM it!'  This could be very
> good for getting the 'v2' flavor into early adopter's hands (e.g. svn dev folk.)

I'll RM it!  But not now ;).

But 2.2 will not be the version Subversion 1.0 will standardize on.  Support yes,
standardize, no.
> Best 'o luck, and please make certain we really use decent error code
> handling, I know I refactored some of that, but I don't remember if I ever
> finished it entirely.

Let's hope Ben stays interested ;).  Even after he now discovered the issue isn't
that big for Subversion anymore... :) :)  [Hi Ben]


View raw message