apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <rbl...@gmail.com>
Subject Re: Opaque structures in general (was Re: Opaque apr_pool_t structure)
Date Fri, 06 Jun 2008 16:28:07 GMT
I agree with Sander, this should be relatively easy to implement using
parent relationships.  And, I didn't intend sarcasm.  I really meant
that if you have a feature that APR is missing, it is better to
implement it inside APR, rather than implement a wrapper around the
existing concept.

Ryan

On Fri, Jun 6, 2008 at 12:16 PM, Sander Striker <s.striker@striker.nl> wrote:
> On Fri, Jun 6, 2008 at 5:10 PM, Yann <yl@bee-ware.net> wrote:
>> Christopher Key wrote:
>
> [...]
>> Ryan Bloom wrote:
>>> If this is what you really want/need, then I would suggest focusing on
>>> a patch that implements this functionality.
>>>
>>> Ryan
>>>
>>
>> OK, I can try to do that although I feel some sarcasm in your suggestion,
>> don't you think it is possible ?
>
> I'm not sure if I really understand what you need.  It sounds like you'd want to
> have something like
>
> /**
>  * Detach @a p from it's parent, making it an orphan.  Destruction or cleanup of
>  * the original parent pool will not destruct @a p.
>  *
>  * @warning Use this function wisely, you're changing original lifetimes.
>  */
> apr_status_t apr_pool_orphan(apr_pool_t *p);
>
> /**
>  * Attach @a p to @a parent, making it a child pool.  Destruction or cleanup of
>  * @a parent will also destroy @a p.
>  *
>  * @warning Use this function wisely, you're changing original lifetimes.
>  */
> apr_status_t apr_pool_adopt(apr_pool_t *p, apr_pool_t *parent);
>
> If that's what you want it's not particularly hard to do.
>
>> Moreover, my solution looks quite simple and I'm afraid it has already been
>> discussed in this list, but I give a try ...
>>
>> If I had to do a patch, I would try to use the
>> apr_pool_cleanup_register()ing / _kill()ing mechanism to bind the pools each
>> others.
>
> I would just manipulate the child/parent relationships.
>
>> Including the subpools that would just be pools registered in the cleanups
>> list of their parent/owner.
>>
>> Do you see another constraint, for a pool to be lately attached to another
>> parent/owner, than the two pools have to use the same allocator and the
>> to-attach pool *not* to be an ancestor of the attached owner/parent pool
>> (that is, not having its own cleanup registered in the owner) ?
>>
>> I'm surely missing something, and I surely need some advices,
>> regards,
>> Yann.
>
> Cook up a patch and we'll give it a look :)
>
> Cheers,
>
> Sander
>



-- 
Ryan Bloom
rbb@apache.org
rbb@rkbloom.net
rbloom@gmail.com

Mime
View raw message