Date: Tue, 14 Aug 2012 23:09:11 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: davidxu@freebsd.org Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-hackers@freebsd.org Subject: Re: system() using vfork() or posix_spawn() and libthr Message-ID: <20120814210911.GA90640@stack.nl> In-Reply-To: <502A6B7A.6070504@gmail.com> References: <20120730102408.GA19983@stack.nl> <20120730105303.GU2676@deviant.kiev.zoral.com.ua> <20120805215432.GA28704@stack.nl> <20120806082535.GI2676@deviant.kiev.zoral.com.ua> <20120809105648.GA79814@stack.nl> <5029D727.2090105@freebsd.org> <20120814081830.GA5883@deviant.kiev.zoral.com.ua> <502A1788.9090702@freebsd.org> <20120814094111.GB5883@deviant.kiev.zoral.com.ua> <502A6B7A.6070504@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 14, 2012 at 11:15:06PM +0800, David Xu wrote: > But in real word, pthread atfork handlers are not async-signal safe, > they mostly do mutex locking and unlocking to keep consistent state, > mutex is not async-signal safe. > The malloc prefork and postfork handlers happen to work because I have > some hacking code in library for malloc locks. Otherwise, you even > can not use fork() in signal handler. This problem was also reported to the Austin Group at http://austingroupbugs.net/view.php?id=62 Atfork handlers are inherently async-signal-unsafe. An interpretation was issued suggesting to remove fork() from the list of async-signal-safe functions and add a new async-signal-safe function _Fork() which does not call the atfork handlers. This change will however not be in POSIX.1-2008 TC1 but only in the next issue (SUSv5). A slightly earlier report http://austingroupbugs.net/view.php?id=18 just requested the _Fork() function because an existing application deadlocked when calling fork() from a signal handler. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120814210911.GA90640>