From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-73805-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 28686 invoked by alias); 7 Oct 2016 14:44:44 -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 28672 invoked by uid 89); 7 Oct 2016 14:44:44 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=
X-HELO: mail-qk0-f182.google.com
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:mime-version:in-reply-to:references:from:date
         :message-id:subject:to:cc:content-transfer-encoding;
        bh=XdXxRtC1Z4emQq1LDE8iFcfu1HQfH8Az/lKxJ2+9nbM=;
        b=QanN40J/cFloDeIok33xnioX+qRinU7qz3UzJfx2V6OQhFKcqga99uqtEYaYiHFThh
         ygJUnMCxrPx/QpYM5jzat5qsuwRjFIw4JvY81/A4nP5YKhtJnfrFpwSD97Wdzxk6d+bx
         TMjQWe07ejh3x84tnj7l3kkD4GKpdFtArw7KmUmlIJCPxUb3Jb6kqXcH3YCwr+HDhI3f
         vgyAtdTWdlLE5EoQi4UYCtzFCJj5IxRUHkzKY6mgjXyY4O9kj3Bb9k0d24FhAZd0Dumz
         3PpQuRSt61cf8XnxlBRsYFZI2jWpQJoDDfag2n1ywMzhiucIQZznAkpNmJVPR2fEfAQX
         t9BQ==
X-Gm-Message-State: AA6/9RmaG9tx2fJFNaNgci2JnxLK1crlY2HptH5kkT9UrI2knOSJ8NKgdSiaJo+iIGByKPyxIFN2XLDQkOBruA==
X-Received: by 10.55.77.201 with SMTP id a192mr21286030qkb.198.1475851472178;
 Fri, 07 Oct 2016 07:44:32 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <CAKCAbMg+FzVQmSu2+yOZXngxb9z9hp6vHfKZJv_vwVs3UJMs_Q@mail.gmail.com>
References: <CAP145pj+yVz_7ZF8_dNqZ2NE22A_O5QyT195Gy0TgvKq1j3skw@mail.gmail.com>
 <20161006172631.GO19318@brightrain.aerifal.cx> <CAP145pjLiwhx4P3XJQCBrpg=OBmaHWyHHOkvT82eSJ4s8aFLZQ@mail.gmail.com>
 <20161006180514.GP19318@brightrain.aerifal.cx> <CAP145phG3DL2nFmA32Lu2J_aQEahKT1CoZrNJaGDn76Mov32Ww@mail.gmail.com>
 <CAP145pgU=Ph1UHntkZoEFwneEGCVzzb8YhyzjJBt69wxPemRkg@mail.gmail.com>
 <CAKCAbMhZ4ddn3RrqkKg2fr_x_pK6X7DwmPVfb3ZLvcZJqGVJJA@mail.gmail.com> <CAKCAbMg+FzVQmSu2+yOZXngxb9z9hp6vHfKZJv_vwVs3UJMs_Q@mail.gmail.com>
From: =?UTF-8?B?Um9iZXJ0IMWad2nEmWNraQ==?= <robert@swiecki.net>
Date: Fri, 07 Oct 2016 14:44:00 -0000
Message-ID: <CAP145piogrms_OXBSrNsrVM8RH6d0sVv4A5UgyF-BGqz1RdBHQ@mail.gmail.com>
Subject: Re: Caching of PID/TID after fork
To: Zack Weinberg <zackw@panix.com>
Cc: Adhemerval Zanella <adhemerval.zanella@linaro.org>, GLIBC Devel <libc-alpha@sourceware.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-SW-Source: 2016-10/txt/msg00165.txt.bz2

2016-10-07 2:43 GMT+02:00 Zack Weinberg <zackw@panix.com>:

>> 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.

Maybe..

 __clone3(unsigned long clone_flags, void* newsp, pid_t*
parent_tidptr, pid_t* child_tidptr, void* tls);

?

__clone2 seems to be used with ia64 already.

--=20
Robert =C5=9Awi=C4=99cki