On Wed, Jul 09, 2014 at 10:13:34AM -0400, Adam Edgar wrote: > Very few implementations of malloc are reentrant. Making malloc thread safe > without locking is not a trivial task. Using malloc within a signal trap is > frowned upon in my experience.
Indeed, the main problem could be that within signal handlers most library functions can become in some cases nonreentrant functions, The correct way seems to be (volatile) sig_atomic_t variables and/or setjmp/longjmp pair (BSD) or maybe a context switch (SysV). This would also allow to use the memory allocation of the glibc. > On Jul 9, 2014, at 6:36 AM, Dr. Werner Fink <[email protected]> wrote: > > > Hi, > > > > even with _AST_std_malloc==0 and _map_malloc==1 I see sometimes that > > the test suite hangs for ever in signal.sh. After attaching the gdb > > to such a hanging ksh process I can identify that this happens in > > the signal handler sh_fault() if the Siginfo structure is allocated. > > The back trace shows that the ksh hanging at last in a nanosleep() > > call within tvsleep() called below src/lib/libast/vmalloc/ > > > > In other words even the libast variant of memory allocation is not > > reentrant. > > > > Werner > > Werner ------------------------------------------------------------------ "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
pgpOncSvn7iwU.pgp
Description: PGP signature
_______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
