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