From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103751 invoked by alias); 17 Sep 2018 14:50:36 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 100936 invoked by uid 89); 17 Sep 2018 14:50:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2 spammy=_exit, fork, wrongly, contract X-HELO: brightrain.aerifal.cx Date: Mon, 17 Sep 2018 14:50:00 -0000 From: Rich Felker To: David Newall Cc: Adhemerval Zanella , libc-alpha@sourceware.org Subject: Re: [PATCH 2/3] posix: Use posix_spawn on popen Message-ID: <20180917145025.GJ17995@brightrain.aerifal.cx> References: <20180915151622.17789-1-adhemerval.zanella@linaro.org> <20180915151622.17789-2-adhemerval.zanella@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker X-SW-Source: 2018-09/txt/msg00242.txt.bz2 On Sun, Sep 16, 2018 at 02:43:02PM +0930, David Newall wrote: > It seems to me that there are still reasonable questions about > whether to use posix_spawn or vfork ("posix_spawn is a badly > designed API").  For (well over) 30 years, I've understood that > vfork was the go-to call for a fork/exec scenario, so, what is the > technical problem with using it for popen and system?  (I'm not > asking about vfork's overall technical merits, I'm asking > exclusively about using it for popen and system.) The historical contract of vfork is that you can basically do nothing after it returns in the child except for exec or _exit, and there are good reasons for this; sharing memory and stack with the parent has lots of subtle issues, especially in the presence of a non-dead-stupid compiler. One thing to note is that vfork is completely unsafe to use as documented if any signal handlers are installed, unless you block all signals before calling vfork, in which case the exec'd process will inherit a fully-blocked signal mask which is probably not what you want. Otherwise signal handlers may wrongly run in the child that's sharing memory with the parent. The posix_spawn implementation already takes care of these issues by not sharing the stack and uninstalling any signal handlers before unmasking signals. Rich