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. > 2. |libc::malloc()| is _slow_ as molasses See above. > 3. |libc::malloc()| cannot be used in signal handlers while the AST > version allows this I think even libumem's malloc is not async signal safe (but if I'm wrong I'm sure Jonathan will correct me; the manpages, however, don't mention umem being async signal safe). In this case keep your allocator BUT DROP THE PREFIX (i.e., let it interpose on libc's. > A while aho when I was in MPK there was a discussion whether it would > make sense to rip-out the existing |libc::malloc()| and port the libast > implementation over to libc. The only problem so far was finding enougth > free time to do it... ;-( I think I'd rather see libumem replace the default allocator. > > Incidentally, private allocators have helped find RLTD bugs, so they've > > been useful in that sense, but that's about it. 6778453 comes to mind. > > Uhm... see above... Er, what? Nico --
