timeless wrote:
> On Thu, Feb 19, 2009 at 8:37 PM, Roland Mainz
> wrote:
> I was trying to point out that the "...but that's about it ..." is IMO
> > not correct - custom allocators may make sense if they have extra
> > features or prevent the application acting in an undesireable way (for
> > e
On Thu, Feb 19, 2009 at 8:37 PM, Roland Mainz wrote:
I was trying to point out that the "...but that's about it ..." is IMO
> not correct - custom allocators may make sense if they have extra
> features or prevent the application acting in an undesireable way (for
> example performance or excessi
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 hav
Roland Mainz wrote:
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 repl
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 standar
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
On Wed, Feb 18, 2009 at 07:42:29PM +0100, Roland Mainz wrote:
> 3. |libc::malloc()| cannot be used in signal handlers while the AST
> version allows this
How does it allow this?
Cheers,
- jonathan
> A while aho when I was in MPK there was a discussion whether it would
> make sense to rip-out the
Glenn Fowler wrote:
> aren't there some solaris build modes that bind certain
> library symbols at link time?
Yes, building with -B direct, though those can still be overridden
by objects marked by the linker as interposers.
http://docs.sun.com/app/docs/doc/819-0690/aehzq?a=view
http://blogs.sun.
Nicolas Williams wrote:
>
> On Sun, Feb 15, 2009 at 01:21:28AM -0500, Glenn Fowler wrote:
> > ast provides its own malloc/free, and those calls are mapped
> > to _ast_malloc/_ast_free in the ksh/ast code for opensolaris builds
> > so that call to free() in the stack trace was not done directly by
On Wed, Feb 18, 2009 at 09:59:26AM -0800, Jonathan Adams wrote:
> On Wed, Feb 18, 2009 at 11:39:02AM -0600, Nicolas Williams wrote:
> > malloc()/free() from libc (or interposed via pre-loading).
> >
> > Rationales:
> >
> > [...]
> > - you need to make sure no more than one allocator uses brk()/
On Wed, Feb 18, 2009 at 11:39:02AM -0600, Nicolas Williams wrote:
> On Sun, Feb 15, 2009 at 01:21:28AM -0500, Glenn Fowler wrote:
> > ast provides its own malloc/free, and those calls are mapped
> > to _ast_malloc/_ast_free in the ksh/ast code for opensolaris builds
> > so that call to free() in th
On Sun, Feb 15, 2009 at 01:21:28AM -0500, Glenn Fowler wrote:
> ast provides its own malloc/free, and those calls are mapped
> to _ast_malloc/_ast_free in the ksh/ast code for opensolaris builds
> so that call to free() in the stack trace was not done directly by
> any ksh/ast code
I believe this
On Wed, Feb 18, 2009 at 01:03:25AM -0500, Glenn Fowler wrote:
>
> On Tue, 17 Feb 2009 21:30:48 -0800 Edward Pilatowicz wrote:
> > libumem is a drop in place replace for libc malloc()/free(). so if an
> > application never uses libc malloc()/free(), then it should never use
> > libumem malloc/free.
On Wed, Feb 18, 2009 at 12:39:02AM -0500, Glenn Fowler wrote:
>
> On Wed, 18 Feb 2009 06:14:59 +0100 Roland Mainz wrote:
> > Glenn Fowler wrote:
> > > well not mentioning libumem in the original message was quite an omission
>
> > Erm... AFAIK libumem isn't the source of the problem. Solaris's libu
On Wed, Feb 18, 2009 at 06:14:59AM +0100, Roland Mainz wrote:
> Glenn Fowler wrote:
> > On Fri, 13 Feb 2009 15:19:30 -0800 Edward Pilatowicz wrote:
> > > >
> > > > What does $ /usr/xpg4/bin/file /usr/bin/sleep /usr/bin/alias # say on
> > > > the system where this fails ?
> >
> > well not mentioning
Glenn Fowler wrote:
> On Fri, 13 Feb 2009 15:19:30 -0800 Edward Pilatowicz wrote:
> > to reproduce the problem you have to have libumem loaded.
> > i've changed the synopsys to be:
> > ksh93+libumem+time/ptime is broken in non-C locales
>
> > to run with libumem, set the following in your en
16 matches
Mail list logo
