This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: nptl refactoring; nacl port

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]