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

Re: svn commit: rev 7296 - trunk/subversion/bindings/swig

From: Russell Yanofsky <rey4_at_columbia.edu>
Date: 2003-10-07 15:41:21 CEST

Greg Stein wrote:
> On Mon, Oct 06, 2003 at 03:43:00PM -0400, Russell Yanofsky wrote:
>> Greg Stein wrote:
>> ...
>>> I'd ask that this change is reverted, and the logic for ctx.config
>>> be updated to accept a Python dictionary.
>> Ok. But what pool should I create the temporary hash in?
> Good point. In most other cases, we snag a pool from the function's
> argument list, and make that available to the type conversions. But
> this is a bit different... the Python user is going to write:
> ctx.config = config
> There isn't a function call in there :-)
> That's a real tough one. Grrr...
> I wonder if it is reasonable to have a hidden pool in that "ctx"
> object. Whenever we make an assignment, then we use that pool for
> allocations. The underlying C binding would take a pool argument.
> The next question is then "which subpool does that belong to?" I'd
> say it is the same pool at the the underlying client_ctx was
> allocated within. Of course, then we have a danger of repeated
> assignments (which are seemingly zero-mem-consuming) will actually
> suck down a lot of memory.
> Damn good question! Do any of my ideas sound acceptable? (I'm not
> going to ask if they sound reasonable :-)

I don't think the idea of reusing the pool "client_ctx was allocated within"
will work without some additional changes. client_ctx isn't allocated in a
pool, it's a normal refcounted python object allocated on the heap. I think
the most natural solution (if you're going to insist on automatic dictionary
<-> hash conversion) would be to allocate the hash in a heap. Its lifetime
should depend on what happens with the ctx object, not on what happens to
some caller's pool. But it doesn't look like there's any way to tell
apr_hash_make to just use malloc.

- Russ

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 7 15:42:27 2003

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.