bjorn3 commented on issue #5255:
The rustix crate wasmtime already uses has futex support. memory.atomic.{notify,wait32,wait64} are modeled after the futex model afaik, not the thread parking model that parking_lot_core exposes. In addition parking_lot_core is modelled on top of futex on Linux. As such using rustix::thread::futex will likely require less code and be more efficient.
bjorn3 edited a comment on issue #5255:
The rustix crate wasmtime already uses has futex support. memory.atomic.{notify,wait32,wait64} are modeled after the futex model afaik, not the thread parking model that parking_lot_core exposes. In addition parking_lot_core is modelled on top of futex on Linux. As such using
rustix::thread::futex
will likely require less code and be more efficient.
haraldh commented on issue #5255:
@bjorn3
I had a futex solution here, but we need a solution for other OSes and AtomicU64, too.
haraldh commented on issue #5255:
@bjorn3 see also this comment
bjorn3 commented on issue #5255:
Didn't think of wait64. That is indeed an issue.
haraldh commented on issue #5255:
Implemented
parking_spot
as aparking_lot_core
replacement.
haraldh commented on issue #5255:
Err... SIGKILL is hard in the CI :)
haraldh edited a comment on issue #5255:
Err... SIGKILL is hard in the CI :)
edit: maybe a timeout killer?
alexcrichton commented on issue #5255:
Oh, and to reiterate, this will require tests to merge.
haraldh commented on issue #5255:
Oh, and to reiterate, this will require tests to merge.
@alexcrichton wouldn't that need threading support first, to test it in full action?
alexcrichton commented on issue #5255:
It would indeed, and everything necessary should be implemented in Wasmtime today. There are, for example, already tests with threads.
haraldh commented on issue #5255:
Addressed some of the issues, working on the others. Now tested with my real pthread example.
haraldh commented on issue #5255:
So, I setup the aarch64 cross compile locally and it passes... just takes some time:
wasmtime/crates/parking_spot on feature/atomic_wait_notify via 🦀 v1.65.0 took 42s [debian-toolbox:latest] ❯ cargo test --target aarch64-unknown-linux-gnu --locked -p wasmtime-parking_spot --lib Compiling wasmtime-parking_spot v4.0.0 (/home/harald/git/wasmtime/crates/parking_spot) Finished test [optimized + debuginfo] target(s) in 0.78s Running unittests src/lib.rs (/home/harald/git/wasmtime/target/aarch64-unknown-linux-gnu/debug/deps/wasmtime_parking_spot-91a65de835bf666b) running 13 tests test tests::atomic_wait_notify ... ok test tests::parking_lot::hundred_unpark_all_one ... ok test tests::parking_lot::unpark_one_fifty ... ok test tests::parking_lot::unpark_all_one ... ok test tests::parking_lot::unpark_one_one ... ok test tests::parking_lot::unpark_one_fifty_then_fifty_all ... ok test tests::parking_lot::unpark_one_hundred_fast ... ok test tests::parking_lot::unpark_one_one_fast ... ok test tests::parking_lot::unpark_one_fifty_then_fifty_all_fast ... ok test tests::parking_lot::unpark_all_hundred ... ok test tests::parking_lot::unpark_all_hundred_fast ... ok test tests::parking_lot::hundred_unpark_all_one_fast has been running for over 60 seconds test tests::parking_lot::unpark_all_one_fast has been running for over 60 seconds test tests::parking_lot::hundred_unpark_all_one_fast ... ok test tests::parking_lot::unpark_all_one_fast ... ok test result: ok. 13 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 98.13s
haraldh commented on issue #5255:
Oh, and to reiterate, this will require tests to merge.
@alexcrichton added one basic test... more to follow
github-actions[bot] commented on issue #5255:
Subscribe to Label Action
cc @peterhuene
<details>
This issue or pull request has been labeled: "wasmtime:api"Thus the following users have been cc'd because of the following labels:
- peterhuene: wasmtime:api
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
haraldh commented on issue #5255:
Looks reasonable to me, thanks!
One thing that we'll want to add is embedder APIs to interact with these instructions as well. For eample I think we'll want
SharedMemory::{notify,wait32,wait64}
which are basically the same wasm instructions but callable bywasmtime
embedders, allowing programmatic interactions with threads as well. That doesn't need to be added necessarily in this PR, however, but it might motivate movement of the implementation of these instructions intowasmtime_runtime::SharedMemory
instead of keeping it in libcalls in the long run.added
Shared::Memory::atomic_*
methods.
github-actions[bot] commented on issue #5255:
Subscribe to Label Action
cc @fitzgen
<details>
This issue or pull request has been labeled: "fuzzing"Thus the following users have been cc'd because of the following labels:
- fitzgen: fuzzing
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
Last updated: Dec 23 2024 at 12:05 UTC