Add futex wrapper to glibc?

[Torvald Riegel]

On Wed, 2014-10-29 at 19:07 -0700, Darren Hart wrote:
> On Sun, Oct 26, 2014 at 03:19:22AM -0400, Mike Frysinger wrote:
> > On 23 Oct 2014 21:06, Joseph S. Myers wrote:
> > > On Thu, 23 Oct 2014, Carlos O'Donell wrote:
> > > * Otherwise, my inclination would be to default to adding wrappers (both 
> > > for syscalls not used in glibc, and for cases such as futex where the 
> > > syscall is used in glibc but can usefully be used directly as well) unless 
> > > there is a clear reason not to.  This includes for architecture-specific 
> > > syscalls.
> > 
> > i disagree here.  if the func is not going to be generally useful, i don't think 
> > glibc should pick it up.  especially for arch-specific syscalls.  i think the 
> > kernel itself is much better suited for providing a thin wrapper layer for 
> > userspace as they're directly in control of the ABI (especially cross-arch) and 
> > the API (via the UAPI headers), they can provide a full API for all syscalls 
> > (unlike glibc per the caveats listed above), and it means there's a central 
> > source point for everyone to use, not just glibc.
> > 
> > if the syscall is generally useful to people writing userland code, then i don't 
> > see a problem with incorporating it in some fashion into the official GNU API.
> > 
> 
> Agreed, and we have at least a couple examples of futex usage outside of glibc.
> 
> (futextest - OK, that one's self-serving, librcu, and I've heard of others)

Yes, there are and will be others, for example GCC's libitm, or C++'s
std::synchronic<T> if it gets accepted.