Re: [PATCH] NUMA spinlock [BZ #23962]

["H.J. Lu" <hjl dot tools at gmail dot com>]

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.