On 05/14/2014 08:28 PM, H. Peter Anvin 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. > 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. Careful there. There is *some* danger in using clone(2) because of the coordination required to implement thread-local storage. I'm sure you're aware of this, but I'd like the record to show that we're going to need clear documentation of what's considered safe given the known implementations. Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
