From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 16 00:07:03 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 DD21F106564A; Thu, 16 Aug 2012 00:07:03 +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 A08698FC08; Thu, 16 Aug 2012 00:07:03 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so654676pbb.13 for ; Wed, 15 Aug 2012 17:07:03 -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=pgKLO3AyRrEwqG/8FRVfzd+0zLzbQDgUydbOcb2Kaig=; b=wYwAE8GeV2iLMi/XtTmj76LnxmKN8KcolHQieSAAxI+rJzpVs8lZ5K7hR5L+Pt32U+ g0DP+w3K7Aqzx+A3k1ed0Um1dIrOcbBPm0fxjJOdXKnq35mQkBuTcewsSufxGqVsi1nM XUKX47vdeDC7/7EpznrabeP2I8X5AtBb/MUE8popXieUU3yBTOItumsdipMCQ+LvtkU1 93VFxcbWfnrp6zb96Jh7lyg/s4Pq6Y0HbytrP7LVxl6/hT4Ls1V7IhAOy4+OVFC2mbix 5PK76FzK7rk/oik//tSxefVGO8eQgdGHHg5x/adADmepNgER3tkA1SuuhQSGaNkBMzz+ rzRw== Received: by 10.68.213.97 with SMTP id nr1mr25469338pbc.105.1345075623103; Wed, 15 Aug 2012 17:07:03 -0700 (PDT) Received: from xp5k.my.domain ([115.192.132.92]) by mx.google.com with ESMTPS id pa6sm1373665pbc.47.2012.08.15.17.07.00 (version=SSLv3 cipher=OTHER); Wed, 15 Aug 2012 17:07:02 -0700 (PDT) Message-ID: <502C39A2.7010608@gmail.com> Date: Thu, 16 Aug 2012 08:06:58 +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: davidxu@freebsd.org 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> <20120815174609.GM5883@deviant.kiev.zoral.com.ua> <502C3775.8090401@gmail.com> In-Reply-To: <502C3775.8090401@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , freebsd-hackers@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:07:03 -0000 On 2012/08/16 07:57, David Xu wrote: > On 2012/08/16 01:46, Konstantin Belousov wrote: >> On Tue, Aug 14, 2012 at 11:15:06PM +0800, David Xu wrote: >>> You are requiring the thread library to implement such a mutex >>> and other locks, that after vfork(), the mutex and other lock types >>> must >>> still work across processes, the PTHREAD_PROCESS_PRIVATE type of >>> mutex and other locks now need to work in a PTHREAD_PROCESS_SHARE >>> mode. >> In fact, yes. In my patch I achieve this by single-threading the parent, > I still think single-threading is execussive, vfork should be fast, and > because parent thread is already waiting for child process, there > is no problem to reuse the parent's stack in child process, it is > compatible. >> which means that existing _PRIVATE mutexes are enough. > > Well, you forget that if private mutex sleep-wakeup queue is in kernel, > you only can see it in same process, otherwise it is a security problem. > Now It works because it is me implementing umtx in such a way that it > comparings two vmspace pointers in kernel umtx code, and treat two > threads are in same process if they are same. But there are > implementations > do not work in this way, they simply look up lwpid in same process, > and if > not found, the mutex is broken. process-private and proecess-shared locks > work in very different way, then your assumptions is false. > I must say my implementation is a lucky, not is the intention.