2011/5/2 <darkjames-ws@xxxxxxxxxxxx>:
> On Mon, May 02, 2011 at 02:12:39AM +0400, Max wrote:
>> it costs one additional pointer per each memory chunk allocated.
>
> Actually why dtor member is inside emem_chunk_t struct? and not inside emem_header_t? :>
Because there are two modes the memory pool can work with.
One that uses emem_alloc_glib() - it allocates one emem_chunk_t each
time you call *e_allloc(). It uses
emem_header_t only to chain these chunks for deallocation. Thus for
each allocation we need a space
to store the pointer to the destructor. That is why I choosed the
emem_chunk_t - it is the most obvious.
The second mode that uses emem_alloc_chunk() allocates big chunks on
per demand basis and then
breaks this chunk into small allocations. But destructor in this case
can be called (or not) for every
allocation. So the space (if needed) to store the destructor pointer
is allocated within each allocation in very
similar way like the canaries do. In that case I use pointer in
emem_chunk_t to refer the last destructor in chain.
>
>> I would gladly read you comments, critics and suggestions regarding this patch.
>
> It seems that you put dtor data before canary, and you execute dtors before checking one.
> Buffer overflows can lead to executing code from given pointer.
Frankly speaking, I don't know how canaries work but suppose you are
right. I can change the order if you
are sure that order matters.
> About API I'd prefer smth like: se_register_gc_dtor(void *ptr, emem_dtor_cb dtor)
> which would register already allocated ptr.
>
> (+) It'd work with any se_* allocated memory.
> (+) you can register it any time (not only at allocation)
> (-) you should check if ptr is valid pointer (se_verify_pointer())
Can you provide a usecase for such an API? Are you sure that you
really often decide during runtime whether you need destructor or not?
:)))
--
Max