Shouldn't this also be paired with a monotonic time opcode?
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- wasm
- Domain
- operating-systems
Research direction
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.
Written by the indexing model from the issue text.
Description
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);
- Most Unix-like:
- The ACPI timer can be used as a clock reference even on older desktops.
- Processors:
- x86, x86-64: HPET,
rdtsc * base frequencyon 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_gettimeimplementations for various architectures.
- x86, x86-64: HPET,
I propose something like an atomic.clock.get that returns an i64 nanosecond count, to align with the existing wait opcodes.
- Dominant language
- WebAssembly
- Stars
- 767
- Forks
- 54
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from WebAssembly/threads
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
WebAssembly/threads#254 ·
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
WebAssembly/threads#253 · 6 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
WebAssembly/threads#245 · 1 reaction ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
WebAssembly/threads#240 ·
-
Branch renaming Open
Difficulty 1/5 Under an hour Newbie friendliness 20/100
WebAssembly/threads#237 ·
All issues in WebAssembly/threads
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
nextbsd/nextbsd-userland#285 ·
-
Bug Good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
johnsonjh/emu2-cpm86#61 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
arduino/arduino-app-lab#49 ·