[ILUG] programming query...

[kevin lyda]

On Sat, Jul 28, 2001 at 05:09:07PM +0100, Padraig Brady wrote:
> I've never done this and I'm not convinced it will work.
> By using mmalloc you seperate the "main" app heap from those
> used by shared libraries, thus allowing you to throw away the
> leaky heap for a shared lib, and reloading the lib.

i have the code to those shared libs - they're being written here.
what i worry about are the libs i don't have source to (or do but am
unwilling to change - glibc, mysql, etc).  and the shared libs will use
those libraries.  if you'll note the mmalloc package just #defines the
malloc workalikes so at the very least the external shared libs would
need to be relinked.  alternatively i think malloc is a weak link in
glibc that my app can override.  still risky though.

> 1. If you don't have access to the code of the shared libs they
>     will use standard malloc calls which mmalloc will map to standard
>     allocations in a (global?) sbrk managed region. I.E. you won't be
>     able to throw away this heap.

> 2. looking @ the ld.so man page I noticed:
>     "
>     BUGS
>            Currently ld.so has no means of  unloading  and  searching
>            for compatible or newer version of libraries.
>     "
>     So you would have to use the dl interface to do it yourself, which
>     will be awkward if you have many entry points to the shared lib(s).

ye gods!  ld.so magically loading new shared libs on demand - now
that would be a bug!  no, dlopen and dlclose are the way to go here.
that way you can shut down the services provided by the module cleanly
and then bring it back up cleanly.

yes, there are entry points but they're well defined entry points.

kevin

-- 
kevin at suberic.net          simple four line sigs -
fork()'ed on 37058400      bandwidth friendly; nice to do.
meatspace place: home      some admins clueless.
http://suberic.net/~kevin          --netiquette haiku 2001