This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mallinfo not 64-bit clean


Hello,

Sorry for the delay, but I have thought about this some more.

> How about the following alternative!  Check out ioctl(2).  Here is an
> interface that is extensible, time proven, etc.
> int get_malloc_statistics(int request, ...)
> 
> You can setup some defines for the request,
> #define  MALLOC_ALL_ARENAS   000000  /* get summary data for all arena's
> */
> #define  MALLOC_CURR_ARENA   000001  /* get data for current arena */
> #define  MALLOC_SELECT_ARENA 000002  /* specify arena of interest */

This would be ok too, I only note a few aspects:

- not really very efficient in the common case if you want to get
  _complete_ stats (unless we pass back a big struct -- then we are
  back with my proposed patch), but that would be fine with me -- I
  really cannot believe malloc stats are performance-critical

- MALLOC_SELECT_ARENA would be thread-unsafe, it would be _much_
  better to always specify the arena number or a magic value for
  "current arena" (of the calling thread) in the "..." parameters

- not typesafe...

> This interface is time tested, efficient, extensible, etc.  Not only
> does this allow
> moving malloc_stats out of malloc, so stdio isn't there, it also avoids
> adding
> in a bunch of data formatting commands into malloc.

Yes.  I think a good solution is either

(A) such a get_malloc_statistics() call: this function would need to
    be within libc, but I think it could well become
    get_libc_statistics() for a more general interface, there are
    surely more interesting variables in the C library than just
    malloc stats

or:

(B) export "struct opaque * _int_get_arena(int n)" from libc like in
    my proposed patch, and do all the messy versioned processing in a
    separate library _outside_ libc.  Note that global (non
    arena-related) info can be obtained from the already exported
    malloc_get_state().

Either way it would be just _one_ new exported function in libc, and
no foreseeable incompatibilities/restrictions.  Uli, what would you
prefer?

Regards,
Wolfram.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]