[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: CVS update: MODIFIED: libsvn_wc ...

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-06-13 01:41:07 CEST

On Tue, Jun 12, 2001 at 12:43:24PM -0500, cmpilato@collab.net wrote:
> Karl Fogel <kfogel@collab.net> writes:
>
> > I think I'm in the same boat as you, Greg: feel funny about using
> > pools this way, but don't have a better idea. Adding an extra
> > argument -- no, pair of arguments, since we need a baton too -- to
> > just about every library function certainly seems worse.
> >
> > In the absence of a super-clever better idea, hanging this stuff off
> > the pool is probably the best course, for sufficiently low values of
> > "best".
>
> Would it make anyone feel better to realize that when the actual APR
> library functions use pools, they pass them around not as "pools", but
> refers to them instead as "contexts" ? In other words, just because
> the primary motivation for the existence of pools is simplified memory
> management, they were apparently built specifically to represent
> nestable code contexts.

That was during a drive to call pools "contexts". The tide turned against
that, so the pool name was retained. The whole "context" stuff happens to
remain simply because people haven't bothered to clean it out.

A pool is a pool :-)

Regarding the vtable hanging off the pool: why don't we simply wait and see
what functions we define? At some point, we can review it and see if there
is another place to attach/pass the callback. (e.g. how many layers down is
that callback? isn't there some kind of abstraction to attach it to?)

Note that people's "funny" feeling is derived from the simple fact that
we're using pools as a way to avoid a global variable. The vtable and error
pools are "global" in scope, but we obscure that.

The error pool isn't as bad as the vtable, though: it is still related to
memory handling. And it is entirely conceivable that the error pool stuff
should be scoped -- the pool applies a scope.

The vtable isn't quite the same, we aren't necessarily saying "here is the
callback for <this> scope."

All that said: *if* you have a scope (e.g. "attach <this> to <that>
request"), then I do find that attaching stuff to a pool makes sense. It
does provide a "context" for an operation.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:31 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.