[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 2005-11-18, aj <aj@xxxxxxxxxx> wrote:
allegro src code seems to have many instances of malloc() thruout the code.
there is also a wrapper for malloc in allegro.c (line646)
void *_al_malloc(int size)
{
return malloc(size);
}
is there any reasons why all those malloc() calls could not use the
_al_malloc() ?
No.
Anyway, we need a design for user-specified malloc functions. Grzegorz
already had one here:
http://alleg.sourceforge.net/future/custom_memory_management.txt
I would only add:
void *al_malloc_atomic(size_t);
It is to be used for allocating blocks of memory which are guaranteed
not to contain any pointers. This is useful for using conservative
garbage collectors. The object being worked on by al_realloc() will be
taken to be atomic iff the old object was atomic. These are the
semantics used by the Boehm GC library.
what all this talk of garbage collectors?
1. allegro is a C library right ?
2. is free() really so slow that we need to use a garbage collector ?
I would consider deleting the `opaque' parameter from his proposal.
It doesn't seem that useful and it breaks the function signatures of
malloc/free/realloc.
This is for 4.3, but part of the patches can probably be backported to 4.2.
Peter
and an answer to my 2nd question: if i submit a patch to modify all
the malloc() to use al_malloc() will it be accepted ?
(waste of time if not accepted, that is why i must ask)
i know the whole thing is going to get a design, and changes (as
mentioned already), but is there any reason why we still cant change all
the malloc's to _al_malloc() in the mean time ?
aj.