From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-66876-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 21487 invoked by alias); 3 Feb 2016 11:07:02 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 21476 invoked by uid 89); 3 Feb 2016 11:07:02 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=
X-HELO: mx1.redhat.com
Message-ID: <1454497614.4592.392.camel@localhost.localdomain>
Subject: Re: [PATCH v2 3/3] posix: New Linux posix_spawn{p} implementation
From: Torvald Riegel <triegel@redhat.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: Florian Weimer <fweimer@redhat.com>, libc-alpha@sourceware.org
Date: Wed, 03 Feb 2016 11:07:00 -0000
In-Reply-To: <56B0AFBB.4050402@linaro.org>
References: <1454343665-1706-1-git-send-email-adhemerval.zanella@linaro.org>
	 <1454343665-1706-4-git-send-email-adhemerval.zanella@linaro.org>
	 <56B0A9B7.6000507@redhat.com> <56B0AFBB.4050402@linaro.org>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-SW-Source: 2016-02/txt/msg00047.txt.bz2

On Tue, 2016-02-02 at 11:31 -0200, Adhemerval Zanella wrote:
> 
> On 02-02-2016 11:05, Florian Weimer wrote:
> > On 02/01/2016 05:21 PM, Adhemerval Zanella wrote:
> > 
> >> +  new_pid = CLONE (__spawni_child, STACK (stack, stack_size),
> >> +		   CLONE_VM | CLONE_VFORK | SIGCHLD, &args);
> > 
> > Does this set up new per-thread variables?  Otherwise, errno in the
> > parent and child will be same and the code still has races.
> > 
> > Florian
> > 
> 
> Could you elaborate? In my understanding there is no requirement of
> using CLONE_SETTLS to avoid races: CLONE_VFORK will suspend the 
> calling process and even with child using the same TLS namespace as
> the parent there will be no concurrent access between them.

Whatever you agree on eventually, it sounds as if this should be
documented as part of the concurrency notes for this function.