Re: __ASSUME_PRIVATE_FUTEX and __ASSUME_FUTEX_CLOCK_REALTIME

[Torvald Riegel <triegel at redhat dot com>]

On Wed, 2015-06-10 at 13:50 -0700, Roland McGrath wrote:
> > >From a non-Linux perspective, I think the question is (1) whether you
> > want to have hooks at your disposal that initialize flags on program
> > startup, 
> [...]
> > It seems you don't need (1) right now because you ignore private/shared
> > and you know a priori whether NaCl supports absolute timeouts.
> 
> That's correct.  In the possible future where shared futex support becomes
> available, startup code would determine what's available and then
> consulting global variables for that later is simple enough.
> 
> > and (2) whether we want to make the decision of private/shared
> > at datastructure initialization time vs. at futex call time.
> 
> I'm not following this part.

Several of the pthread data structures combine the availability of
private futexes and the choice the user makes into a final flag on data
structure initialization time (futex_private_if_supported in my new API
is a helper function for that).  We could do that, and then futex_*
don't need to check/transform on the calls.  Alternatively, we could
check whether the requested private/shared is actually supported during
each futex_* call, and adapt accordingly.  The latter might be a tiny
bit of overhead, but futex_* calls are basically always on slow paths.
If we can do the latter, we can remove futex_private_if_supported and
all that.

> > Would shared or private be unsupported in practice, ever?  
> 
> Yes.
> 
> > If shared is unsupported, this only matters if one can indeed map glibc
> > data structures between processes -- so only if that other functionality
> > does not return an error.
> 
> It is certainly not a well-supported case in NaCl today, but it is not
> completely impossible.

Ok.

> > If private is unsupported, shared is fine as well.
> 
> Agreed.  That case exists only for older Linux, and not for any
> configuration we support or particularly anticipate supporting later.
> 
> > Would you still like to see the futex API offering an is_supported()
> > function or such?
> 
> Yes.  I want pthread_*_setpshared on NaCl to be able to fail with ENOTSUP
> for PTHREAD_PROCESS_SHARED.

OK.

> > Regarding the clocks, only condvars use it currently AFAIK.  I'll have
> > to have a closer look at what the existing condvar impl really did and
> > whether I've handled it correctly in the new condvar impl.  If there is
> > anything to change in the futex API, I'll introduce that with the patch
> > that moves the new condvar over to the new API.
> 
> OK.  Again my concern is that pthread_condattr_setclock have a sysdeps
> call it can make to validate the clockid_t.  It should be general like
> that rather than something equivalent to __ASSUME_FUTEX_CLOCK_REALTIME
> because NaCl's situation is that it actually supports only
> CLOCK_REALTIME and not CLOCK_MONOTONIC for pthread_cond_t.  Some cleanup
> or abstraction of the way it stores the clock selection in the struct
> wouldn't hurt either.  (For Linux that would do its current thing of
> fudging it into one bit; for NaCl it would just do nothing since there
> is no actual choice available to record.)

OK, noted.  I'll see what I can do.