Shouldn't this also be paired with a monotonic time opcode?

Sleep timers are normally batched for performance, with durations turned into deadlines, and effective batching requires tracking a monotonic clock to know precisely how long to wait for. In fact, processors normally mandate such batching at the operating system level. And this primitive is implemented on every platform, from embedded CPUs to high-performance operating systems, as it's a strict necessity.

Here's the API on various relevant platforms:

• Operating systems:
  • Most Unix-like: clock_gettime(CLOCK_MONOTONIC, &tv);
  • Linux: clock_gettime(CLOCK_BOOTTIME, &tv);
  • Windows: QueryInterruptTime(&ticks);
• The ACPI timer can be used as a clock reference even on older desktops.
• Processors:
  • x86, x86-64: HPET, rdtsc * base frequency on modern processors
  • ARM: Generic Timer system register
  • RISC-V: memory-mapped mtime
  • AVR doesn't natively, but real-time clock peripherals are pervasive, and Arduinos have them built-in.
  • Others also have their various ways - just look at the Linux VDSO clock_gettime implementations for various architectures.

I propose something like an atomic.clock.get that returns an i64 nanosecond count, to align with the existing wait opcodes.

Start with the existing wait opcodes in the threads proposal's Overview.md and review the platform clock APIs listed here. Determine whether a monotonic clock opcode belongs alongside them and document the proposed API and its expected time representation. Done means the proposal has a resolved design rather than an open question.