From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76283 invoked by alias); 13 Sep 2018 12:11:17 -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 76269 invoked by uid 89); 13 Sep 2018 12:11:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=Adhemerval X-HELO: EUR02-HE1-obe.outbound.protection.outlook.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=94i8jJu4PfodxhuEoTQfCTxV4nMOyRDQkzVV+zMb6dw=; b=hUSeAGdEHJ9vq1CRp9o/vdOylVJ0lhRZD2S4ctCcAF88ENBZz+eV25HPHWIcEzy+9so7g1tNBrGQQ4a8WdPVBmekX95hq7NyWK+oE9LBTzgX6W3Y3pKMdKLVw8pyRdBtMGUdC27JAj1eftB3KNqmF8OnsPacuJSGCN81oJBLBDo= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs.Nagy@arm.com; Cc: nd@arm.com, libc-alpha@sourceware.org Subject: Re: system and popen fail in case of big application To: Zack Weinberg , adhemerval.zanella@linaro.org References: <0caab9ea-5c2c-fe37-385b-090b21dd3cbb@linaro.org> From: Szabolcs Nagy Message-ID: <05593924-cd6b-9099-c177-5d7828bc3189@arm.com> Date: Thu, 13 Sep 2018 12:11:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-Path: szabolcs.nagy@arm.com Received-SPF: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-SW-Source: 2018-09/txt/msg00182.txt.bz2 On 12/09/18 17:29, Zack Weinberg wrote: > I don't want to encourage people to use posix_spawn because > posix_spawn is a badly designed API. It's difficult to use correctly. > It's *tedious* to use correctly, which means people won't bother. It > can't do everything you might want to do on the child side (witness > the discussion of adding an extension to let it do chdir()). Its > behavior in case of errors is underspecified. And it might be the misdesigned api is vfork: it is not just difficult to use correctly but impossible: it breaks c language semantics (gcc fixes this up to some extent when it sees the actual vfork symbol in the code, but there is no guarantee in c that the compiler can see that, and even then the shared stack between parent and child has various issues as Adhemerval described) so stop telling ppl to use vfork. fork has the problem of large commit charge so it can fail with oom, it's also not implementable efficiently on various systems (no-mmu, windows, etc) can easily cause leaks of sensitive data into child processes (hard to provide security boundary between parent and child during the critical operations before exec) posix_spawn is ugly but at least was designed with the c language in mind and currently it's the only api that avoids the problems listed above, so until there is a better api, this is what should be recommended for process creation (e.g. gnu make would benefit from it, its vfork usage is a pile of UB) > implemented in terms of fork, which means it doesn't guarantee to > solve Sergey's problem. vfork can be implemented in terms of fork too, memcpy can be implemented using syscalls, these are QoI issues and not good technical reasons to avoid a particular api. (the entire point of posix_spawn is that it does not depend on the va space copy semantics of fork, the way glibc ignored this for a long time was just a glibc bug)