This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Add futex wrapper to glibc?
- From: Torvald Riegel <triegel at redhat dot com>
- To: Darren Hart <dvhart at infradead dot org>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, "Carlos O'Donell" <carlos at redhat dot com>, Rich Felker <dalias at libc dot org>, Roland McGrath <roland at hack dot frob dot com>, GLIBC Devel <libc-alpha at sourceware dot org>, Michael Kerrisk <mtk dot manpages at gmail dot com>
- Date: Thu, 30 Oct 2014 10:31:22 +0100
- Subject: Re: Add futex wrapper to glibc?
- Authentication-results: sourceware.org; auth=none
- References: <1410881785 dot 4967 dot 292 dot camel at triegel dot csb> <20140917194100 dot 23B722C26C5 at topped-with-meat dot com> <1410983178 dot 27838 dot 27 dot camel at triegel dot csb> <20140917195918 dot 6F06C2C3974 at topped-with-meat dot com> <20140917231708 dot GC23797 at brightrain dot aerifal dot cx> <544953F7 dot 1020607 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1410232050160 dot 19073 at digraph dot polyomino dot org dot uk> <20141026071922 dot GA21885 at vapier> <20141030020701 dot GH14609 at vmdeb7>
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.