This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Add futex wrapper to glibc?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Rich Felker <dalias at libc dot org>, Roland McGrath <roland at hack dot frob dot com>
- Cc: Torvald Riegel <triegel at redhat dot com>, GLIBC Devel <libc-alpha at sourceware dot org>, Darren Hart <dvhart at infradead dot org>, Michael Kerrisk <mtk dot manpages at gmail dot com>
- Date: Thu, 23 Oct 2014 15:16:07 -0400
- Subject: 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>
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.
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.
However, per other discussions on errors, I'd actually add a non-trivial
C wrapper to enforce that the kernel does not return error codes that
are unexpected.
Roland expressed some opinions in the past. I think, because I can't find
the reference, they were along the lines that: the value of all of these
things being in glibc is suspect.
I'm OK with distinct symbol sets between supported OSs and I understand
that for GNU/Linux that glibc *is* part C library and part Linux library.
Cheers,
Carlos.