On Fri, Jun 6, 2008 at 5:10 PM, Yann <[EMAIL PROTECTED]> 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
