apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann ...@bee-ware.net>
Subject Opaque structures in general (was Re: Opaque apr_pool_t structure)
Date Fri, 06 Jun 2008 09:02:37 GMT
I'm sorry to insist on this point but, in general, maybe you should consider having a function
that provides the 
sizeof() each opaque structure/type of the APR (maybe not all of them, but at least some).

That would let the user "play" with the opaque types without breaking the interest (portability,
evolution ...) of this 

As far as I know, the APR is a C programming API, so let us play with the pointers if we find
it usefull.

I could propose the patch(s) if you agree and/or are interested by that.
If not, maybe you could let me know why ?

Thanks for your answers,

>> Sander Striker wrote:
>>> Hello,
>>> I'm making a piece of software that recycles apr_sockets in 
>>> sockets-pools.
>> Have you looked at apr_reslist in apr-util?
> It looks very interesting, thank you for the hint, however it seems that 
> I have to do the same trick to prevent a leak with my_socket (a stucture 
> containing the apr_socket and other things associated with it).
> As the pool used to create the reslist is passed to the contructor for 
> its own allocations (my_sockets here), I suppose I have to create a 
> subpool in the constructor where my_socket will be allocated, and keep a 
> reference to the subpool in my_socket to be able to release all that in 
> the destructor.
> Without this, that is using the reslist pool directly, memory will leak 
> as my_socket allocated fields or even the apr_socket internals (addr and 
> like) will stay in the pool after destruction.
> Did I miss something ?
>>> Each socket is allocated and created on its own pool (not a subpool, or
>>> exactly a subpool of the internal global pool only).
>>> I've read on svn programming pages that it is not recommanded to do 
>>> this,
>>> but I find it very usefull, that's the power of pools, IMHO.
>> The problem is the memory footprint that this brings with it.  Each pool
>> will pre-allocate 8k of memory.
> Maybe a subpool doesn't pre-allocate memory, or the problem remain with 
> reslists (and the method above).
>>> Anyway, to make the things clean, I need a way to attach/detach pools
>>> to/from others, whether the socket belongs to the socket-pool's pool 
>>> or to
>>> the user's one.
>>> As the apr_pool_join() function is a noop (and I don't knwow if 
>>> that's its
>>> purpose anyway), I used the apr_pool_cleanup_register()ing /
>>> apr_pool_cleanup_kill()ing mechanism to attach / detach pools between 
>>> them.
>>> I create a small new API with my pools based on the APR ones, where I 
>>> can
>>> attach/detach pools, as I said, but also malloc() and realloc() memories
>>> attached to a pool (with the same registering mechanism).
>>> My pool struct is like :
>>> struct my_pool_t {
>>>  apr_pool_t pool;
>>>  apr_pool_t *owner;
>>> };
>>> And the functions :
>>> apr_status_t my_pool_create(my_pool_t **pool, void *owner);
>>> apr_status_t my_pool_attach(my_pool_t *pool, void *owner);
>>> apr_status_t my_pool_detach(my_pool_t *pool);
>>> apr_status_t my_pmalloc(void *pool, apr_size_t size);
>>> apr_status_t my_pzalloc(void *pool, apr_size_t size);
>>> apr_status_t my_prealloc(void *pool, void *ptr, apr_size_t size);
>>> void my_pfree(void *pool, void *ptr);
>>> As you can see with the first element of the struct which is an APR 
>>> pool and
>>> 'void*' types used in functions, I expect the functions to be 
>>> "compatible"
>>> with the APR ones, that is I can use my_pool_t and apr_pool_t pools
>>> indistinctly with them (where the type is void*) ...
>> That's not the case, see below.
> Hum, I see, the pool stands in an allocator node, see below.
>>> My problem is that I can't initialize my_pool because I haven't got the
>>> sizeof(apr_pool_t), an opaque structure ...
>>> I understand the advantages of opaque types, but is there a way an
>>> apr_pool_sizeof() function be added (and exported) in the APR, simply 
>>> like :
>>> APR_DECLARE(apr_size_t) apr_pool_sizeof(void)
>>> {
>>>  /* maybe the aligned SIZEOF_POOL_T should be used */
>>>  return sizeof(apr_pool_t);
>>> }
>>> With it, I could at least do :
>>>  apr_pool_create(&p, NULL);
>>>  memcpy(my_pool->pool, p, apr_pool_sizeof())
>> This would be a bad idea, as you'd be copying pointers and the like, 
>> which
>> would be off as soon as copied.  Even if that were not the case, the 
>> apr_pool_t
>> struct instance lives in an allocated block of memory from which the pool
>> will hand out memory.  This block in turn is managed by an allocator.
> But the allocator node shouldn't be destroyed (or reused) while the pool 
> isn't, so I don't see why a copy of the pool couldn't do the job as well.
> The copy of the pointers and the like still reference the allocator 
> node, and it should work.
> However all this becomes cheat and I'd better look at apr_reslist.
>>> Or should I consider using my_p*() functions strictly with my_pools ?
>>> Thanks for your advices, answers.
>> Cheers,
>> Sander
> Cheers, and thanks for your answers,
> Yann.

View raw message