From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-99071-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 46781 invoked by alias); 5 Jan 2019 16:36:25 -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 46764 invoked by uid 89); 5 Jan 2019 16:36:24 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=U*carlos, sk:carlos, sk:carlos@, customer
X-HELO: mail-oi1-f194.google.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=vKD377OFg6qZH4mO4KLNaQONnLuFlsTCtwOtA53KfFE=;
        b=CFytlgLAk/FTSDL5Lf6JP6MRkO1EXDFZ+JB5gy+bXhorxc9hqhWuxy3uYgQavTr1Fu
         yeTqW8wJwBFn56Usj7npGRjpf7BOcm6ZLEG7L93M+/dmw1jD1pSSFdjuvd/Woh5SO90v
         +m9X2hLYbc5/C5wg6rmGyGjzN/tNtHcGjPm2MNwGJ+YbhnfbDptiTIbdrteg1lqi9+dM
         eiYh7g5QrpIWcCd4OtYqPyaG9RdVwL2/mfMVSx+uNa5+zOxy7inxbgEFd7WbCys0lKUM
         wlYWTzDLeOfxjmzM2XgrFoxVlZgOP1uqAwikwrfyTnKPlRR+oMe2l7/6JtC5TWViIMyg
         f0Kg==
MIME-Version: 1.0
References: <20181226025019.38752-1-ling.ma@MacBook-Pro-8.local>
 <7D8A82D6-6F0A-4860-856A-EB0C8CD13E9C@antfin.com> <0a474516-b8c8-48cf-aeea-e57c77b78cbd.ling.ml@antfin.com>
 <c7f11fea-371e-4453-b5d0-9b142632aecc.ling.ml@antfin.com> <8c67f319-31bf-818b-4a89-66d25328026e@arm.com>
 <CAMe9rOrU1niqVofiFvpgvMNrUohu0yW--OBTHh3TDC-3fnG51Q@mail.gmail.com> <d4b9e25e-8884-b01f-040e-b6f40e011033@redhat.com>
In-Reply-To: <d4b9e25e-8884-b01f-040e-b6f40e011033@redhat.com>
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Sat, 05 Jan 2019 16:36:00 -0000
Message-ID: <CAMe9rOr9yeey0H2R1H6LRQxiFJ1Eu2fc+sqs+J2t1aaJBFcC5g@mail.gmail.com>
Subject: Re: [PATCH] NUMA spinlock [BZ #23962]
To: "Carlos O'Donell" <carlos@redhat.com>
Cc: Szabolcs Nagy <Szabolcs.Nagy@arm.com>, libc-alpha <libc-alpha@sourceware.org>
Content-Type: text/plain; charset="UTF-8"
X-SW-Source: 2019-01/txt/msg00141.txt.bz2

On Sat, Jan 5, 2019 at 4:34 AM Carlos O'Donell <carlos@redhat.com> wrote:
>
> On 1/3/19 2:58 PM, H.J. Lu wrote:
> > +libpthread {
> > +  GLIBC_2.29 {
> > +    numa_spinlock_alloc;
> > +    numa_spinlock_free;
> > +    numa_spinlock_init;
> > +    numa_spinlock_apply;
> > +  }
> > +}
>
> Why are we adding these non-standard interfaces to glibc?
>
> The API implementation doesn't rely on any special glibc internals.
>
> It could be implemented as a distinct library, allowed to evolve quickly
> in response to customer need, and eventually integrated into glibc if the
> API proves stable. A similar model has been setup by Boost and C++ just to
> draw some parallels.
>
> I'm not happy to see new APIs like this go directly into glibc without
> much more discussion about *why* they have to be in glibc initially.
>
> Just to be clear I have a sustained objection to this new set of APIs
> being added to glibc until I can be convinced that they have to go in
> glibc.
>

Should glibc have scalable spinlock, in libc.so or a separate shared object?
Or should we tell people that if they want scalable spinlock, they look
elsewhere?

-- 
H.J.