Re: configure bits for clock_nanosleep and nanosleep.

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi,
> To implement sleep_for/sleep_until in 30.2.2 (std::this_thread) I can
> use clock_nanosleep if available, and if not, nanosleep if its
> available. If neither are available I think there's ways to emulate
> those functions using condition variables as a fall back.
>
> nanosleep is available in glibc. clock_nanosleep is the same deal as
> clock_gettime, either libposix4 or librt.
>   
Ok... (so to speak ;)
> For clock_nanosleep, its first input is one of CLOCK_REALTIME or
> CLOCK_MONOTONIC, both are already checked in the clock_gettime check.
> I was thinking about extending the clock_gettime check to include
> clock_nanosleep as well. Does this seem like the best way? It
> unfortunately means that the --enable-clock-gettime option would also
> extend to clock-nanosleep. The alternative I guess is to make an
> --enable-clock-nanosleep with exactly the same logic as gettime.
>   
I guess, if the two checks are actually related and both end up 
involving librt, for now the best solution is renaming the existing 
check to a more generic name making clear  to the library builder that 
this is all about "timing" facilities (and also that the important 
difference in the options is between libc + libposix4 and librt). Then, 
inside the function, implementing the checks in a compact way but 
defining different macros for clock and sleep.
> For nanosleep, I'm checking for it spearately but is an AC_TRY_COMPILE
> sufficient or do we need a TRY_COMPILE_OR_LINK as well?
>   
Well, if you know already that, when available, is in general available 
in libc and not elsewhere, "normally" AC_TRY_COMPILE should be enough. 
*But*, since after all nanosleep is part of Posix, it is well possible 
that other implementations of the C library besides glibc are delivering 
it but only optionally, maybe in the annoying way (which we know well by 
now) of declaring it in the header but not defining in the library, thus 
GCC_TRY_COMPILE_OR_LINK  seems safer.

Paolo.