[Issue 14863] CLOCK_BOOTTIME should be optional to support <2.6.39 kernels

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14863

--- Comment #2 from Steven Schveighoffer <schveiguy at yahoo.com> ---
According to clock_getres, it should return -1 with a value of EINVAL for
errno. So this seems like an issue with the kernel. I've never heard of a
system call causing a segfault like this.

However, I noticed that we have an assert(0) if that happens. This shouldn't be
the way it's handled. If we get the "Invalid clock" return value, we should
only assert if someone actually tries to USE that clock (put in some sort of
sentinel value for the resolution).

In addition, we should be checking the kernel version and only doing
CLOCK_BOOTTIME, if the kernel version is high enough (and skipping otherwise,
put in the sentinel value). I still think lazy initialization is incorrect.

Jonathan, I see it's assigned to you, I can look into this if you want.

(In reply to Jonathan M Davis from comment #1)
> I guess that in one of the rounds of changes that we made
> relating to static constructor bugs must have resulted in the clock
> frequency being grabbed for all of the ClockTypes that the system supports
> (or at least supposedly supports). *sigh*

If you recall, it was because of the issue with static constructors being used
in templates cause any importing module to be flagged as containing static
constructors. So we now construct all the resolutions eagerly (which shouldn't
cause issues like this).

I think lazy initialization is not what we need, when someone uses an
"unsupported" clock, they should not get a segfault either. Neither would the
original solution of only eagerly fetching clocks that are instantiated (the
segfault would then occur in a static ctor). The only correct answer is to
eliminate the segfault.

--