Re: __ASSUME_PRIVATE_FUTEX and __ASSUME_FUTEX_CLOCK_REALTIME

[Roland McGrath <roland at hack dot frob dot com>]

> On Fri, 2014-06-20 at 16:15 -0700, Roland McGrath wrote: 
> > > __ASSUME_PRIVATE_FUTEX and __ASSUME_FUTEX_CLOCK_REALTIME are defined for 
> > > all supported Linux kernel versions.  Should we say they are a required 
> > > part of the futex interface for any system, whether or not using the Linux 
> > > kernel, that may wish to use NPTL, and so remove these macros and all 
> > > conditionals testing them everywhere in glibc, not just in 
> > > sysdeps/unix/sysv/linux/ files?
> > 
> > Please, no.  Other systems that provide a futex layer may well provide a
> > much less fully featureful one than Linux has.
> 
> Roland, do you see any reason why having __ASSUME_FUTEX_CLOCK_REALTIME
> or not couldn't be contained in the internal futex abstraction layer?
> That is, we could have a futex_timed_wait that just does the right thing
> on Linux, and does something different but conforming on non-Linux?
> This might be similar for __ASSUME_PRIVATE_FUTEX, but I haven't looked
> at this closely.

I certainly think that these variations should be folded into the new
internal futex interface in some fashion.  There is nothing to love about
the existing #if nests.  At the time of this discussion, I was displaying a
bit of generic paranoia about changing things in ways that might make life
more difficult for me in the NaCl port.  Now we have the context of the
NaCl port in the tree so all my concerns will be addressed by taking care
to make sure new internal interfaces make things better for the NaCl port,
which can now be seen concretely.  NaCl's futex support is about as minimal
as futex support could be, but may well be augmented in the future; so
something that is a good fit for today's Linux as well as NaCl should cover
the theoretical spectrum well.

In fact, I'd like the new internal interface to cover the issue of varying
feature support so as to be a user-visible improvement for the NaCl case.
That is, make sure that functions like pthread_condattr_setclock and
pthread_mutexattr_setpshared diagnose the unsupported features up front.


Thanks,
Roland