This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] NUMA spinlock [BZ #23962]
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.