wasmerio/wasmer · error · panic

wasi::platform_clock_time_get(wasi::Clockid::ProcessCputimeI

Error message

wasi::platform_clock_time_get(wasi::Clockid::ProcessCputimeId, ..)

What it means

On Windows, wasix's platform_clock_time_get has no implementation for the ProcessCputimeId clock, so requesting process CPU time panics with this unimplemented! message. Other clocks (e.g. realtime/monotonic) are supported on Windows, but CPU-time clocks were never wired up.

Source

Thrown at lib/wasix/src/syscalls/windows.rs:47

    precision: Timestamp,
) -> Result<i64, wasi::Errno> {
    let nanos = match clock_id {
        wasi::Snapshot0Clockid::Monotonic => {
            let tick_ms =
                unsafe { windows_sys::Win32::System::SystemInformation::GetTickCount64() };
            tick_ms * 1_000_000
        }
        wasi::Snapshot0Clockid::Realtime => {
            let duration = std::time::SystemTime::now()
                .duration_since(std::time::UNIX_EPOCH)
                .map_err(|e| {
                    debug!("Error in wasi::platform_clock_time_get: {:?}", e);
                    wasi::Errno::Io
                })?;
            duration.as_nanos() as u64
        }
        wasi::Snapshot0Clockid::ProcessCputimeId => {
            unimplemented!("wasi::platform_clock_time_get(wasi::Clockid::ProcessCputimeId, ..)")
        }
        wasi::Snapshot0Clockid::ThreadCputimeId => {
            unimplemented!("wasi::platform_clock_time_get(wasi::Clockid::ThreadCputimeId, ..)")
        }
        _ => return Err(wasi::Errno::Inval),
    };
    Ok(nanos as i64)
}

View on GitHub (pinned to 8c4b9ee9d3)

Solutions

Avoid requesting ProcessCputimeId on Windows; use MonotonicClock/Realtime clocks instead.
Guard the guest code with a platform check and fall back to wall-clock time on Windows.
Implement the Windows variant in windows.rs using GetProcessTimes() and return the CPU time as nanoseconds instead of panicking.

Example fix

// before
wasi::Snapshot0Clockid::ProcessCputimeId => {
    unimplemented!("wasi::platform_clock_time_get(wasi::Clockid::ProcessCputimeId, ..)")
}
// after (Windows implementation idea)
wasi::Snapshot0Clockid::ProcessCputimeId => {
    let mut creation = 0; let mut exit = 0; let mut kernel = 0; let mut user = 0;
    unsafe { GetProcessTimes(GetCurrentProcess(), &mut creation, &mut exit, &mut kernel, &mut user) };
    (user.saturating_add(kernel)) * 100 // FILETIME 100ns -> ns
}

Defensive patterns

Strategy: fallback

Validate before calling

// guest/host-side: detect Windows before requesting CPU-time clocks
#[cfg(windows)]
fn supports_cputime_clock() -> bool { false }
#[cfg(not(windows))]
fn supports_cputime_clock() -> bool { true }

Prevention

Never request ProcessCputimeId on Windows; prefer Monotonic/Realtime clocks
Compile-test WASIX workloads on Windows in CI
Feature-guest CPU-profiling code paths behind a non-Windows check

When it happens

Trigger: A WASI guest calling clock_time_get (snapshot0) with clock id ProcessCputimeId while the runtime executes the Windows code path in lib/wasix/src/syscalls/windows.rs.

Common situations: Guest programs that measure their own CPU usage (profilers, benchmarking code, runtimes like Node's process.cpuUsage equivalents) running under Wasmer on Windows.

Related errors

AI-assisted analysis of wasmerio/wasmer@8c4b9ee9d3 (2026-09-01). Data as JSON: /api/errors/655065a88f7ea6d6. Report an issue: GitHub.