Another awful thing... Valhalla Linux doesn't have a concept of a steady clock within it.
The only clocks I can find for this is a clock that matches the 'real time', and is subject to the usual crap when you adjust the time, and process/thread CPU clocks, which are not exactly steady. There is no way that I can see right now that you can get a kind of clock that simply iterates over a steady rate of time, monotonically.
Did people writing for Valhalla wind up with obscure and weird problems when people changed their time?
(Sorry, I wrote 'Valhalla Linux', which is stupid... RedHat Valhalla is what I mean).
you're supposed to run ntpclient in cron or such.
VM-clocs are even less predictable then usual system clocks.
Ticks are supposed to be somewhat predictable..
what you're looking for might be /proc/loadavg, which is used by the "uptime" command...
/proc/uptime ooks like the the same thing, higher resolution?
(I got this by running "strace" on the /usr/bin/uptime. the program queries both /proc/loadavg and /proc/uptime (oops) so the latter is the one that's relevant.
these have been around for a while, so they should work on rh6.2 even.
Thanks for the information!
Here's something else to add to it:
If I'm reading this correctly, back then, people tried to ensure that time marched forward by relying upon the NTP client to adjust the system clock in monotonic ways. So, you'd never change the system clock yourself... you would let NTP do it for you, and it would always adjust the clock in a fashion that is monotonic in nature.
Obviously, folks must have figured out how bad this idea was, as we now have CLOCK_MONOTONIC available for clocks in current kernels, but I guess we had some relatively naive notions about time back then.
Sooo, at least philosophically, I should be able to use the realtime clock as if it were the steady clock, and avoid adjusting the time/date on the machine, just as I guess they intended back in the day.
I have to figure out how to coerce my code to do this... it *really* wants CLOCK_MONOTONIC or the like. I tried #defining it to CLOCK_REALTIME and now I have a linking error. But I'm sure I can get past that with a little evil.
nm, strings & grep to the hilts!
Heh... I worked around it by forcing the underlying boost::steady_clock class to use CLOCK_REALTIME instead of CLOCK_MONOTONIC (or variations). It isn't perfect, but it'll have to do since the OS doesn't have a proper monotonic clock.
If I felt plucky, I could maybe build one in some bizarre fashion using the boost::steady_clock interface but writing the underlying code that calls the usual OS APIs to do something with /proc/utime instead... if I can figure out how to make a timer that doesn't busy-wait within this context.
But I think for how I'm doing everything, this may be good enough. I'll know more when we get into testing.
Well, there is *One* *Simple* *Trick* that you can do to ensure monotonicity in userland ;) ;) ;)
(oh, and since this kind of stuff gets picked up by Google now, here's some additional details, in case someone else wants to do this).
If you find yourself in the ridiculous position of having to write code to work on a version of Linux using the 2.14 kernel, after figuring out how to build the GCC 4.83 compiler (not something I'll bother with here... just know that it's doable), you'll need the following in one of your .cpp files:
#define CLOCK_MONOTONIC CLOCK_REALTIME
#pragma message "This OS doesn't support a steady clock. YMMV."
Oh, god, that is stupid.
There's another guard... #if !defined(CLOCK_MONOTONIC), that I missed.
Oh, I missed that... 'one simple trick' to ensure monotonicity in userland... RTOS I assume.
I was thinking of something a little more subtle, but still quite silly.
Things related to Linux that you should probably avoid saying in theIt is okay, Don't ask don't tell has been repealed.
Booting the Colonel now.
Free greps for everyone!
Oh, I missed that... 'one simple trick' to ensure monotonicity in
userland... RTOS I assume.
I think I saw that at the bottom of a web page. "Ensure monotonicity in userland with this one weird trick!"
Heh, my clock trick works, but I don't feel great about it.
Whatever I did to get this compiler built on this machine, though, may not be working so well. I can compile code just fine, and much of it works, but apparently, when I do this One Certain Thing, it segfaults.
I don't think it's the code itself, as this One Certain Thing works everwhere else. I'm not in the habit of blaming compilers for my problems, but I suspect this compiler isn't kosher because of my tamperings.
I'm sorely tempted to tell them that the older version of this product is the only thing that will work on this older OS, and that we won't be able to add new features to it. They need to modernize anyway, maybe this could help give them incentive.
valgrind is your friend.
or... didn't you compile GCC 4.8 anyways? try ASAN.
I'm not sure I know what 'ASAN' means.
I did compile gcc 4.8, and that's the compiler I'm using, but... I'm not sure it's doing the trick here. I've also tried compiling with a 4.7 compiler, but that also failed to work for me.
I'm not sure valgrind is going to help me much here, when the symbols are so borked that gdb (as newly compiled by 4.8) can't read them. But I can give it a shot... I've been using nm to help me figure out where the weirdness is happening (pthread_create/pthread_wait_for_restart_signal/pthread_handle_sigrestart).