From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 16 00:23:44 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4657106566B; Thu, 16 Aug 2012 00:23:44 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A78378FC15; Thu, 16 Aug 2012 00:23:44 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so675330pbb.13 for ; Wed, 15 Aug 2012 17:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Bb0uX69VN02yAN+dB2JbIWfko2eTiLqbMn5gY66evbE=; b=N1lyIYW2uO21Nz96WDwG3HPJgg7fJLlA6PzR1KZG0gd33ZqGI1Xybw4NT0rN/p+dfi drNEvxPeY/x80LTTrRK7+0NeTT1ENABfxPmHM2apGNt1EyJyrdazLGCXelM9rnC0k/LV 0QT06NSKYzXIbRfI6hGiFW+1WW1h1/Yuycir/SuvsnmEfVjZCDCeXpIGncmU9I+CFC9N 0Gb24aG/er233yfFdKKsxp2pe2/e+Dq4nI6QaPUI9OHCH0rQiqfY4aPJcJhb7IJXGDLN 74xFseh+NsNcfMuox0BYfqkYOdGr/A+lVcvTnz2UZrS8q282wgJEWMfQ1HKAQOeyyVpM oA3A== Received: by 10.68.220.201 with SMTP id py9mr16998785pbc.137.1345076624108; Wed, 15 Aug 2012 17:23:44 -0700 (PDT) Received: from xp5k.my.domain ([115.192.132.92]) by mx.google.com with ESMTPS id wf7sm1403009pbc.34.2012.08.15.17.23.41 (version=SSLv3 cipher=OTHER); Wed, 15 Aug 2012 17:23:43 -0700 (PDT) Message-ID: <502C3D8B.4060008@gmail.com> Date: Thu, 16 Aug 2012 08:23:39 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120808 Thunderbird/13.0.1 MIME-Version: 1.0 To: Konstantin Belousov 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> <20120815174942.GN5883@deviant.kiev.zoral.com.ua> In-Reply-To: <20120815174942.GN5883@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, davidxu@freebsd.org, Jilles Tjoelker Subject: Re: system() using vfork() or posix_spawn() and libthr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 00:23:45 -0000 On 2012/08/16 01:49, Konstantin Belousov wrote: > 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=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. >>> >> Thanks, although SUSv5 will have _Fork(), but application will not catch up. >> >> 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. My patch is very experimental. There are setcontext and getcontext which also can break it. Another solution would save a flag into jmpbuf or ucontext, and indicates the signal handler is executing. a setjmp or getcontext executed in normal context would not have such a flag, but if they executes in signal handler, the per-thread flag will be saved. but it requires lots of changes, and setcontext and getcontext are syscall, kernel does know such a userland flag, unless they are shared between kernel and userland.