[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.
Regards,
Maciej