[PATCH] NUMA spinlock [BZ #23962]

Carlos O'Donell carlos@redhat.com
Sat Jan 5 12:34:00 GMT 2019


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.

-- 
Cheers,
Carlos.



More information about the Libc-alpha mailing list