This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Add futex wrapper to glibc?
- From: Rich Felker <dalias at libc dot org>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, 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 17:10:06 -0400
- 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.
Perhaps on the bug tracker. IIRC there's at least one duplicate bug
report for it too, and the discussions are probably buried in one of
them.
> 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.
The kernel's commitment to maintain API/ABI is simply a consequence of
all the pthread primitives depending on the behavior. This is at least
as strong as documentation, but I agree documentation would be nice
too, especially for less-known aspects that glibc is not depending on
right now.
> 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.
Is there a reason for this? I don't see it being done on any other
Linux-specific functions glibc provides syscall wrappers for.
> 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 don't think it's any more suspect than epoll, eventfd, fanotify,
sendfile, etc. syscall wrappers being in glibc. These are all Linux
APIs that are useful to applications. Recommending these to be handled
in third-party libraries is not a good idea. Not only does it
perpetuate the use of syscall() (which has ugly variadic calling
issues and issues with argument type on x32 and possibly other future
32-on-64 type ABIs), but it precludes applications from being able to
use them with cancellation. One of the bug reports requesting futex()
is actually about having it as a cancellation point. IMO it would make
sense for just the wait forms to be cancellation points, much like how
fcntl is a cancellation point only for blocking lock operations.
> 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.
Yes. BTW I think it's fundamentally possible to do non-process-shared
futex in userspace if you do want to support it on non-Linux targets.
You just do the equivalent hash buckets/waiter lists wrapped with a
mutex and cond var. Not to say this is a good idea, but it's possible.
Rich