[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pthreads] performance test using fib.scm

From: Maciej Stachowiak
Subject: Re: [pthreads] performance test using fib.scm
Date: Wed, 11 Dec 2002 05:48:13 -0800
User-agent: Mutt/1.2.5i

On 11Dec2002 08:11AM (+0100), Mikael Djurfeldt wrote:
> Maciej Stachowiak <address@hidden> writes:
> > On 10Dec2002 10:10PM (+0100), Wolfgang Jaehrling wrote:
> >> malloc() in glibc is thread-save, but not reentrant.  Since the
> >> behaviour of realloc() is unlikely to differ from malloc() in this
> >> respect, you most certainly have to protect calls to it with a lock.
> >> 
> >
> > Huh? Doesn't malloc do it's own locking when modifying global data
> > structures?
> This is what I would have expected.
> Can someone please verify that malloc is reentrant?

According to the best info I can find on Google, glibc's malloc can be
called safely from multiple threads but cannot necessarily safely be
called from a signal handler (another possible definition of
re-entrant). A mutex would not help with calling it from a signal
handler anyway, though. So don't bother with locking.

If you truly suspect heap corruption I suggest running with
MALLOC_CHECK_=2 set in your environment. This should detect many kinds
of heap corruption.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]