3 ms·

clock_gettime is extremely heavily used by nearly everything. Any form of work queue that supports delayed work, for example, is sitting on clock_gettime. Any f

clock_gettime is extremely heavily used by nearly everything. Any form of work queue that supports delayed work, for example, is sitting on clock_gettime. Any form of media uses it heavily, as does self-monitoring to look for performance regressions in the wild. You might be shielded from this depending on what level you're working at, but there's a reason that vDSO exists basically solely for clock_gettime, too. Yes it allows for timing attacks, but you can't really avoid that, either, not without utterly crippling your platform.

naasking 9y ago
> Any form of work queue that supports delayed work, for example, is sitting on clock_gettime. That seems strange to me. Why would you use the clock/gettime call for that instead of a work counter of some sort?
- kllrnohj 9y ago
  I meant time-delayed. Eg, run this in 10ms type of thing. How else would you do things like exponential backoff?
  - naasking 9y ago
    Right, but your original statement was about clock_gettime, hence my confusion. Something like sleep() is an operation on your own schedule, not an operation on a global system clock. That's not nearly as problematic. Consider if you wanted to virtualize a process, say to deterministically replay it to trigger a fault or something. sleep(100 ticks) doesn't require additional kernel support for virtualization, but an ambient clock requires a lot of extra kernel support. If the clock were only accessible via a handle, then you could proxy invocations on the handle without any extra support in the kernel. See my other comment for more details: https://news.ycombinator.com/item?id=16817462 https://news.ycombinator.com/item?id=16817462
    - kllrnohj 9y ago
      You could use sleep, sure, but then you require a seperate thread for every delayed message, which is a whole different ball of not-fun. Otherwise what actually happens when you do a postDelayed(func, delay) is it immediately is translated into a postAt(func, clock_gettime() + delay). Then as messages are consumed the work queue consistently knows how long it should wait to wake back up, no matter how many delayed tasks are in flight.
      - naasking 9y ago
        I feel like I'm missing some context. I thought you were talking about work stealing in threaded systems, in which case sleeping seems reasonable. Are you instead talking about some kind of event loop? If so, then clock_gettime seems like it's merely convenient, not essential. You could just as easily keep a ticket incremented on successful operations or successive loops (or some other metric), and exponential backoff is a wait operation on a ticket number. Unless you're suggesting the delay must be based on real time for some reason?
        kllrnohj 9y ago
        > You could just as easily keep a ticket incremented [..], and exponential backoff is a wait operation on a ticket number. Congrats, you've re-invented clock_gettime(CLOCK_MONOTONIC) :) You're right that it's not essential to have, but if you can re-implement it then you've also just re-introduced the timing attack that the removal of clock_gettime was trying to prevent. The trivial-ness with which a clock suitable for timing attacks is able to be created is literally why SharedArrayBuffer was panic-removed from all major browsers. Because that's all you need, shared memory & a worker. Congrats, you have a high-precision timer with zero OS support. So as soon as you allow any form of threading or shared memory to occur you've given apps a high precision timer, so you might as well just give them an actual timer, too.
        naasking 9y ago
        > You're right that it's not essential to have, but if you can re-implement it then you've also just re-introduced the timing attack that the removal of clock_gettime was trying to prevent. I'm not convinced. The clock is global, shared among all processes, the ticket I suggested is local to a process, and so can't be used to signal between processes. Unless I'm again missing some context for what you mean.

naasking 9y ago

> Any form of work queue that supports delayed work, for example, is sitting on clock_gettime. That seems strange to me. Why would you use the clock/gettime call for that instead of a work counter of some sort?

kllrnohj 9y ago
I meant time-delayed. Eg, run this in 10ms type of thing. How else would you do things like exponential backoff?
- naasking 9y ago
  Right, but your original statement was about clock_gettime, hence my confusion. Something like sleep() is an operation on your own schedule, not an operation on a global system clock. That's not nearly as problematic. Consider if you wanted to virtualize a process, say to deterministically replay it to trigger a fault or something. sleep(100 ticks) doesn't require additional kernel support for virtualization, but an ambient clock requires a lot of extra kernel support. If the clock were only accessible via a handle, then you could proxy invocations on the handle without any extra support in the kernel. See my other comment for more details: https://news.ycombinator.com/item?id=16817462 https://news.ycombinator.com/item?id=16817462
  - kllrnohj 9y ago
    You could use sleep, sure, but then you require a seperate thread for every delayed message, which is a whole different ball of not-fun. Otherwise what actually happens when you do a postDelayed(func, delay) is it immediately is translated into a postAt(func, clock_gettime() + delay). Then as messages are consumed the work queue consistently knows how long it should wait to wake back up, no matter how many delayed tasks are in flight.
    - naasking 9y ago
      I feel like I'm missing some context. I thought you were talking about work stealing in threaded systems, in which case sleeping seems reasonable. Are you instead talking about some kind of event loop? If so, then clock_gettime seems like it's merely convenient, not essential. You could just as easily keep a ticket incremented on successful operations or successive loops (or some other metric), and exponential backoff is a wait operation on a ticket number. Unless you're suggesting the delay must be based on real time for some reason?
      - kllrnohj 9y ago
        > You could just as easily keep a ticket incremented [..], and exponential backoff is a wait operation on a ticket number. Congrats, you've re-invented clock_gettime(CLOCK_MONOTONIC) :) You're right that it's not essential to have, but if you can re-implement it then you've also just re-introduced the timing attack that the removal of clock_gettime was trying to prevent. The trivial-ness with which a clock suitable for timing attacks is able to be created is literally why SharedArrayBuffer was panic-removed from all major browsers. Because that's all you need, shared memory & a worker. Congrats, you have a high-precision timer with zero OS support. So as soon as you allow any form of threading or shared memory to occur you've given apps a high precision timer, so you might as well just give them an actual timer, too.
        naasking 9y ago
        > You're right that it's not essential to have, but if you can re-implement it then you've also just re-introduced the timing attack that the removal of clock_gettime was trying to prevent. I'm not convinced. The clock is global, shared among all processes, the ticket I suggested is local to a process, and so can't be used to signal between processes. Unless I'm again missing some context for what you mean.