On 03/28/2011 06:15 PM, Rich Felker wrote: > On Sun, Mar 27, 2011 at 10:47:10PM +0300, Timo Teräs wrote: >> On 03/27/2011 10:21 PM, Rich Felker wrote: >>> On Sat, Mar 26, 2011 at 08:28:04PM +0200, Timo Teräs wrote: >>>> Otherwise other threads can leave malloc state locked, and the child >>>> will hang indefinitely if it tries to malloc something. >>> >>> This change by itself breaks as much as it fixes, unless the mutex >>> implementation is reentrant and recursive. fork() is specified to be >>> async-signal-safe, which means it's legal for a signal handler to call >>> fork() while malloc() is being executed. With your patch, this will >>> hang the program. >> >> It is recursive mutex. It's works perfectly fine if same thread locks >> that mutex multiple times. > > But not from a signal handler. There's almost surely a race between > locking the mutex and having it in the right state so that the signal > handler sees it's the owner.
Oh. That's right. There's a race for that. I've been trying to figure how glibc handles that, but it'd seem that it does not. Hmmh. Not sure what to do here. Need to think about it. Any great ideas? -Timo _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
