WASI target: thread::sleep() is panicing: unexpected result of poll_oneoff

[dunnock]

Following code seems correct though will always panic when compiled to wasm32-wasi:

fn main() { std::thread::sleep(std::time::Duration::new(0,5)); }

compiled with nightly rust 1.40:
>cargo +nightly build --target wasm32-wasi

It fails at least in wasmtime and wasmer-js VMs (example https://github.com/dunnock/wabench/tree/master/poll_oneoff_test):

> wasmtime target/wasm32-wasi/debug/poll_oneoff_test.wasm

thread 'main' panicked at 'thread::sleep(): unexpected result of poll_oneoff', src/libstd/sys/wasi/thread.rs:61:18
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace.
error: failed to process main module target/wasm32-wasi/debug/poll_oneoff_test.wasm
    caused by: Instantiation error: Trap occurred while invoking start function: wasm trap: unreachable, source location: @8f01

rustup show:

active toolchain
nightly-x86_64-apple-darwin (default)
rustc 1.40.0-nightly (0e8a4b441 2019-10-16)

[dunnock]

After some more digging it seems down to std::thread::sleep implementation

In __wasi_subscription_t.userdata passed 0 to poll_oneoff, which should set resulting event structure with same number __wasi_event_t.userdata:
https://github.com/rust-lang/rust/blob/master/src/libstd/sys/wasi/thread.rs#L45

Later __wasi_event_t.userdata matched to CLOCK_ID == 0x0123_45678:
https://github.com/rust-lang/rust/blob/master/src/libstd/sys/wasi/thread.rs#L56

Following code is a copy from std::thread::sleep's wasi implementation:

fn debug_std_thread_sleep() {
    // Copied from thread::sleep
    const CLOCK_ID: wasi::Userdata = 0x0123_45678;

    let clock = wasi::raw::__wasi_subscription_u_clock_t {
        identifier: CLOCK_ID,
        clock_id: wasi::CLOCK_MONOTONIC,
        timeout: 5u64,
        precision: 0,
        flags: 0,
    };
    let in_ = [wasi::Subscription {
        userdata: 0, //Should it be CLOCK_ID?
        type_: wasi::EVENTTYPE_CLOCK,
        u: wasi::raw::__wasi_subscription_u { clock: clock },
    }];
    let (res, event) = unsafe {
        let mut out: [wasi::Event; 1] = std::mem::zeroed();
        let res = wasi::poll_oneoff(&in_, &mut out);
        (res, out[0])
    };

    println!("Res = {:?}", res);
    assert_eq!(event.userdata, CLOCK_ID, "event.userdata");
    assert_eq!(event.error, 0, "event.error");
    assert_eq!(event.type_, wasi::EVENTTYPE_CLOCK, "event.type_");
}

Will show:

Res = Ok(1)
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `0`,
 right: `305419896`: event.userdata', src/main.rs:32:5

[mati865]

cc @newpavlov

[newpavlov]

Yes, it looks like CLOCK_ID should indeed go to the userdata field instead of identifier. I was not 100% sure about correctness of the implementation myself and it seems I've misinterpreted the Core API docs at the time (both fields have type __wasi_userdata_t).