On Wed, May 14, 2014 at 5:28 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: > On 05/14/2014 01:56 PM, Davidlohr Bueso wrote: >>> >>>> However, unless I'm sorely mistaken, the larger problem is that glibc >>>> removed the futex() call entirely, so these man pages don't describe >>> >>> I don't think futex() ever was in glibc--that's by design, and >>> completely understandable: no user-space application would want to >>> directly use futex(). >> >> That's actually not quite true. There are plenty of software efforts out >> there that use futex calls directly to implement userspace serialization >> mechanisms as an alternative to the bulky sysv semaphores. I worked >> closely with an in-memory DB project that makes heavy use of them. Not >> everyone can simply rely on pthreads. >> > > More fundamentally, futex(2), like clone(2), are things that can be > legitimately by user space without automatically breaking all of glibc. I'm lost -- I think the missing verb is important :) > There are some other things where that is *not* true, because glibc > relies on being able to mediate all accesses to a kernel facility, but > not here. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
