I realized last night that we're mixing up semantics a bit... Let me pose the following (pseudo)code:
apr_pool_initialize(); apr_allocator_create_with_alt_alloc(&allocator, alloc_fn, free_fn, opaque); // I realized that the allocators should be part of the constructor for the apr_allocator_t type apr_pool_create_ex(&pool, NULL, NULL, allocator); // standard create_ex call char *foo = apr_psprintf(pool, "hello %s", "world"); apr_pool_create_ex(&pool2, pool, NULL, NULL); // what is the semantics of this? apr_allocator_create_with_alt_alloc(&allocator2, alloc_fn2, free_fn2, opaque2); apr_pool_create_ex(&pool3, pool, NULL, allocator2); // ditto, what is the semantics of this? I suppose it's ok to allow child pools to have alternate allocators, the parents will just be unawares of the memory allocated by the children but that's ok? On May 18, 2010, at 7:48 PM, Nick Kew wrote: > > On 19 May 2010, at 02:58, Chris Knight wrote: > >> Ah, makes sense. Yeah would be insane to change the malloc replacement >> mid-stream so an alternate to create_with_allocator is nice. >> >> But you also bring up an important question; I argue that you should only be >> able to do this on a top-level pool, not on a child pool...(In other words, >> create_with_allocator would not take a parent pool pointer.) > > I disagree. You should be able to have the parent pool manage it. > > Example: you have a shm pool. If it's top-level, what's to stop the > shm segment disappearing from under it? But if the shm segment > is created on a pool, and then the shm pool is created on the > same pool (or a child), then you ensure the right sequencing. > > Feel free to rubbish me. It's nearly 4am here, and I can't sleep :( > > -- > Nick Kew
