This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Add futex wrapper to glibc?
- From: Darren Hart <dvhart at infradead dot org>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Rich Felker <dalias at libc dot org>, Roland McGrath <roland at hack dot frob dot com>, Torvald Riegel <triegel at redhat dot com>, GLIBC Devel <libc-alpha at sourceware dot org>, Michael Kerrisk <mtk dot manpages at gmail dot com>
- Date: Wed, 29 Oct 2014 18:59:15 -0700
- 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>
On Thu, Oct 23, 2014 at 03:16:07PM -0400, Carlos O'Donell wrote:
> On 09/17/2014 07:17 PM, Rich Felker wrote:
> > On Wed, Sep 17, 2014 at 12:59:18PM -0700, Roland McGrath wrote:
> >>> I've asked Michael about the current status and offered my help in case
> >>> we also want to document more high-level properties of futex, like how
> >>> to use it properly.
> >>
> >> Thanks for taking this on. The futex(7) man page seems like the right
> >> place for that, and it's rather thin now.
> >
> > I would really like to expose futex(2) as a public interface and see
> > it documented there.. :-) I know that's something of a separate topic,
> > but it seems like a good time to discuss since the documentation is
> > going to be worked on, and since C11 atomics make having futex()
> > available to applications A LOT more desirable.
>
> We've had this discussion before, but I can't find the reference in
> the libc-alpha archives.
>
> The largest problem right now is lack of documentation and that becomes
> lack of commitment from the kernel to maintain the API/ABI, and that
> translates into reluctance for glibc to create a wrapper.
I would like to see this as well so I (and others, like Mathieu Desnoyers) don't
have to do our own syscall wrapper in futextests and librcu, for example.
>
> We are IMO at the stage where futex is stable, few things are changing,
> and with documentation in place, I would consider adding a futex wrapper.
Yes, at least for the defined OP codes. New OPs may be added of course, but that
isn't a concern for supporting what exists today, and doesn't break
compatibility.
I wonder though... can we not wrap FUTEX_REQUEUE? It's fundamentally broken.
FUTEX_CMP_REQUEUE should *always* be used instead. The glibc wrapper is one way
to encourage developers to do the right thing (don't expose the bad op in the
header).
--
Darren Hart
Intel Open Source Technology Center