From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19722 invoked by alias); 7 Oct 2016 18:30:05 -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 19547 invoked by uid 89); 7 Oct 2016 18:30:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=burden, Hx-languages-length:1630, act X-HELO: mail-ua0-f174.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=WrMogqYbu0CZC5HTJOjxlF+BWxeDiwgyLOnlNtzswS4=; b=ledQ8o3BYbIE8CZojFYVm/uNrn8jOaFTXtBnBt1APUMoBRL92Uj34I6eKvFk+h7aOe Q1p9FRI4nXoM+cogdeNThWTJF2Gol400Nm+xbHDvK6fgMG2z2gesdAxXRdfhoz7q6cGc 9WKVqCN6GRgVjzpwruogpHACqzkmdwyLm/+9gjynUEYezSJWm3U2ubHrknTO1TM6DUFi OrPiYdhl1aU5jIk/aq4tFP3pKLpenUPr0R6o39WKqBxhzqk6gkwW8SHg/y12OdB4vWrR wjIiqFxSvh78hierppqmS85L/3XWMqbeuI0isYN3vukkJ9y8sg2idclsdQAT+oqblYa5 yeWQ== X-Gm-Message-State: AA6/9RkKrwkRkjTJfrSahtEjYQ2cZBem+Dgq5kj9CLd56GM4KrwNeYmj2lKGCfYUNLZVuGl8 X-Received: by 10.176.4.75 with SMTP id 69mr13341844uav.146.1475864993119; Fri, 07 Oct 2016 11:29:53 -0700 (PDT) Subject: Re: Caching of PID/TID after fork To: Zack Weinberg , =?UTF-8?Q?Robert_=c5=9awi=c4=99cki?= References: <20161006172631.GO19318@brightrain.aerifal.cx> <20161006180514.GP19318@brightrain.aerifal.cx> Cc: GLIBC Devel From: Adhemerval Zanella Message-ID: <6759a113-e871-b439-f165-2cb1b36cdfe2@linaro.org> Date: Fri, 07 Oct 2016 18:30:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2016-10/txt/msg00172.txt.bz2 On 06/10/2016 21:43, Zack Weinberg wrote: > On Thu, Oct 6, 2016 at 8:42 PM, Zack Weinberg wrote: >> On Thu, Oct 6, 2016 at 5:35 PM, Robert Święcki wrote: >>> Maybe providing something like fork_with_flags(int flags) would work >>> here? Seems that most (all?) the projects that I've seen, which use >>> clone() directly and had problems with caching of TID/PID, basically >>> need fork with some flags (mainly of the CLONE_NEW* type). Such >>> function would deal with tid/gid/locks/pthread_atfork as fork does, >>> but would also OR the provided flags with the canonical ones? >> >> I've thought for quite some time that there should be a second >> clone-wrapper in glibc that doesn't ask for a new stack. It might be >> better to call it something with "clone" in the name, but I don't care >> terribly much. > > Meant to say: in addition to the PID/TID caching issues, this would be > able to run pthread_atfork() handlers. > > zw Adding a new implementation would require either change the clone prototype (since flags is used for the kernel defined ones) or adding a new arch-specific implementation. This is an extra burden on current assembly-only clone variants and for new ports (an extra symbol to implement). The stack check seems just error-prone one and I see it might be justifiable to remove it. I am not sure how we should act on semantic change for Linux-only syscall, so it might require to add compatibility symbol I would try to avoid it. Also, this path would lead to more arch-specific assembly hackery that I would try to avoid.