> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] > 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 allocators. > 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 area. >>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] Sander
