From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 14 23:40:10 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D191A106566B; Tue, 14 Aug 2012 23:40:10 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 62CA08FC16; Tue, 14 Aug 2012 23:40:10 +0000 (UTC) Received: by yenl7 with SMTP id l7so1402800yen.13 for ; Tue, 14 Aug 2012 16:40:09 -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=+RUmvvGZnxklPJ1iFxEW8hhgSAYQkzctTQ77Y+TjEAM=; b=nS7MestaD3K7zITlHhogWpO0NKkiT8l7O/UqN3pNeUWewuvtM1m2M8X9qHc6w4vFML P4N9wJoUJToJcJptN5ZqfLdQ88KpMJ4nLVYNU8W10iiqc5oBw2nDbyRY1tQJTiiqWwl+ KEMYEivwwfkZFVwxkV5NjQAmFCpwupRbQlppJOZiNosn+OWe+R16uzInJagcrcN07q/Q p6UxKQvO/iHUwRduw1dtZvZVa+/7lrwmSBveCVrZK/2zsHgj6qKff56RtfmtRXcz2fJo 3anneSKqhc6P0PE60FvGRp9c4jr3drbWy11gF0LMsaXtswq5r8DoQ7Clw6J0+3UA5Yiq ki8Q== Received: by 10.66.90.67 with SMTP id bu3mr22805453pab.26.1344987608813; Tue, 14 Aug 2012 16:40:08 -0700 (PDT) Received: from xp5k.my.domain ([115.192.128.117]) by mx.google.com with ESMTPS id st6sm34907pbc.58.2012.08.14.16.40.06 (version=SSLv3 cipher=OTHER); Tue, 14 Aug 2012 16:40:07 -0700 (PDT) Message-ID: <502AE1D4.4060308@gmail.com> Date: Wed, 15 Aug 2012 07:40:04 +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: Jilles Tjoelker 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> <20120814210911.GA90640@stack.nl> In-Reply-To: <20120814210911.GA90640@stack.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, davidxu@freebsd.org 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: Tue, 14 Aug 2012 23:40:11 -0000 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.