iximeow

oh my god

arshia it gets so much worse hELP

I feel like every mature codebase I've worked with has dark corners like this and honestly that makes me so afraid for the gabillions of people who DEPEND on this code

no joke check out the lkml post in https://twitter.com/iximeow/status/1114686077015449600 … - commodity hardware rife with so many unknown footguns

this is folks trying to do something useful when the hardware might be actively hostile! i want to scream

who among us has not tried to write a little vidya game where you can just like woosh a wand around or whatever and look cool as hell and instead ended up discovering severe and widespread kernel- or BIOS-level bugs in massively popular platforms

i hear about hardware|driver bugs from folks who touch game engines or graphics pipelines with frightening regularity, and can only conclude these machines are not to be trusted

@iximeow at least you've documented the chaos extraordinary well. I think that's as much as anyone could ask. Letting go of bugs caused by forces outside your software is like learning to let go of things in life that you can't control. It's an exercise in Zen.

oh this particular comment was definitely not me :D

got it

highly unsurprised that it turns out to be acrichton though: https://github.com/rust-lang/rust/blame/master/src/libstd/time.rs#L155 …

Wow, this is inside of #rustlang? What were you building that you ran into this?

iirc i was just curious if i should use this for some short (single digit millisecond) timing measurements or use the rdtscp instruction instead (eg, how is "now" implemented) this turns into gettimeofday which is i'm going to call it Good Enough with the possibility of outliers

(so the use site of this has a note that if outliers become annoying in that direction, maybe switch to rdtscp, a reference to this function, kernel source, and a reminder that i'd trade upward outliers for maybe backwards time measurement)

Hmm, that makes me wonder if https://github.com/python/cpython/blob/bf94cc7b496a379e1f604aa2e4080bb70ca4020e/Python/pytime.c#L764 … might benefit from a similar workaround (cc @VictorStinner). OTOH, the runtime cost of invoking the Python level API call might already be high enough to mask this kind of low level misbehaviour.

fwiw i followed this up with a quick and very incomplete trip through how gettimeofday is implemented - it looks like linux does something similar if time goes backwards, except i think it just waits for time to catch up before returning