This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: nptl refactoring; nacl port
- From: Torvald Riegel <triegel at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: "GNU C. Library" <libc-alpha at sourceware dot org>
- Date: Fri, 09 May 2014 14:58:25 +0200
- Subject: Re: nptl refactoring; nacl port
- Authentication-results: sourceware.org; auth=none
- References: <20140508181240 dot 8E5992C39B1 at topped-with-meat dot com>
On Thu, 2014-05-08 at 11:12 -0700, Roland McGrath wrote:
> There is also lots of code that doesn't really assume Linux, but
> just assumes that there is a futex facility. As NPTL is fundamentally
> based on the futex facility, I don't think there will ever be an attempt to
> port it to a system without such a facility. (NaCl has a futex facility
> and the Hurd's GNU Mach might grow one someday.)
I agree that it seems unlikely to be beneficial to try to port the NPTL
code to a blocking facility other than futexes. It certainly could be
done, but it seems easier to build a futex facility in userspace based
on the blocking facility that is available.
For example, if the underlying OS (or whatever) offers condvars, the
futex port could map the futex variable by address to a condvar/mutex,
execute the futex ops while holding this mutex, and block using the
condvar. That adds some indirection and potentially contention to using
the underlying blocking facility directly, but blocking should be on the
slow-path anyway.