Re: static _int_malloc et al

[Wolfram Gloger <wmglo at dent dot med dot uni-muenchen dot de>]

Hi,

> Why wouldn you want to tie yourself to a specific implementation of
> malloc?  The _int_* functions have no interface which is in any way
> universal and should be preserved if the implementation changes.

Yes, they do -- at least it was my intention to preserve the _int_*
interface for the foreseeable future.  (One of the people requesting
it was Roland.)  Some advantages:

- using them from user-defined hooks is possible.  (Setting the hook
  pointer values "back" to the system values within a hook has some
  problems, in particular it cannot be made thread-safe) So,
  well-performing user-defined hooks can be written easily using
  _int_*.

- when the spinlock patch is in, they can even be used safely from
  within a signal handler.  That AFAICS would provide the only
  possibility to allocate memory in a signal handler in non-pagesize
  chunks, something which you would otherwise have to implement
  yourself with considerable effort.

- plus all of Roland's arguments :-)

> I've changed the code to use static since the generated code uses tail
> calls.  This can perhaps be achieved with hidden as well but for the
> above reasons I need more convincing.

Please keep them public.  If there are performance advantages to be
achieved while keeping them public, please guide me and I will work on
it.

Regards,
Wolfram.