Re: __ASSUME_PRIVATE_FUTEX and __ASSUME_FUTEX_CLOCK_REALTIME

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

> >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.

> 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.

> 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.

> 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.)


Thanks,
Roland