On Thu, Feb 19, 2009 at 07:37:32PM +0100, Roland Mainz wrote: > Nicolas Williams wrote: > > On Wed, Feb 18, 2009 at 07:42:29PM +0100, Roland Mainz wrote: > > > Nicolas Williams wrote: > > > > I strongly recommend that ksh93/AST on Solaris use the standard > > > > allocator, OR, if you insist on having a private allocator, that it > > > > provide an allocator with standard names, so that: a) it interposes upon > > > > libc's, b) remains interposable. > > > > > > The problem with |libc::malloc()| was that it isn't useable in ksh93's > > > case: > > > 1. |libc::malloc()| suffers from excessive fragmentation issues for > > > long-running scripts. It simply doesn't stop growing the heap. > > > > I am not sure that's true, but you should try libumem -- if it works > > then link with libumem. If no Solaris allocator works well enough then > > use your own BUT DO NOT prefix the symbol names with _ast_ or anything > > else -- let your allocator interpose on the system one so as to avoid > > multiple allocators in one process. > > AFAIK this will not work properly if someone uses libumem via LD_PRELOAD > since libumem&co. are not async-signal safe and ksh93 relies on this > feature.
I asked this before with no answer, but how does ksh93 do this without a substantial performance overhead? Cheers, - jonathan
