Date: Wed, 15 Aug 2012 20:49:42 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: davidxu@freebsd.org Cc: freebsd-hackers@freebsd.org, Jilles Tjoelker <jilles@stack.nl> Subject: Re: system() using vfork() or posix_spawn() and libthr Message-ID: <20120815174942.GN5883@deviant.kiev.zoral.com.ua> In-Reply-To: <502AE1D4.4060308@gmail.com> References: <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> <20120814210911.GA90640@stack.nl> <502AE1D4.4060308@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--cs5saTBZh7UZl2eX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 15, 2012 at 07:40:04AM +0800, David Xu wrote: > On 2012/08/15 05:09, Jilles Tjoelker wrote: > >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=3D62 > > > >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=3D18 ju= st > >requested the _Fork() function because an existing application > >deadlocked when calling fork() from a signal handler. > > >=20 > Thanks, although SUSv5 will have _Fork(), but application will not catch = up. >=20 > One solution for this problem is thread library does not execute > atfork handler when fork() is called from signal handler, but it > requires some work to be done in thread library's signal wrapper, > for example, set a flag that the thread is executing signal handler, > but siglongjmp can mess the flag, so I have to tweak sigsetjmp and > siglongjmp to save/restore the flag, I have such a patch: it fetches > target stack pointer stored in jmpbuf, and compare it with top most > stack pointer when a first signal was delivered to the thread, if the > target stack pointer is larger than the top most stack pointer, the > flag is cleared. > I do not understand how this interacts with altstacks. Also, there are longjmp()s implemented outside the base, e.g. in the libunwind, which cannot be fixed this way. Also, there are language runtimes that relies heavily on the (synchronous) signals and which use their internal analogues of the stack unwinding, which again be broken by such approach. --cs5saTBZh7UZl2eX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAr4TYACgkQC3+MBN1Mb4hSMgCfdu6eu3supl2hoDArBYfsip62 cXYAniH1jGKsq2Xch31K6Ku1jY1qjzs2 =1k4c -----END PGP SIGNATURE----- --cs5saTBZh7UZl2eX--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120815174942.GN5883>