Milek7 opened PR #7884 from Milek7:threadid
to bytecodealliance:main
:
TID returned by
wasi_thread_spawn
must be non-zero and upper three bits must always be zero: https://github.com/WebAssembly/wasi-threads?tab=readme-ov-file#design-choice-thread-idsCurrent implementation didn't fulfill this requirements, only clearing the top bit from random value. Additionally, from birthday paradox probability of collision in allowed TID range nears 50% after spawning 27000 threads. This is large but not totally impossible, thus replace random generation with sequential allocation.
Milek7 requested pchickey for a review on PR #7884.
Milek7 requested wasmtime-core-reviewers for a review on PR #7884.
Milek7 edited PR #7884:
TID returned by
wasi_thread_spawn
must be non-zero and upper three bits must always be zero: https://github.com/WebAssembly/wasi-threads?tab=readme-ov-file#design-choice-thread-idsCurrent implementation didn't fulfill this requirements, only clearing the top bit from random value. This breaks wasi-libc mutexes when random TID is larger than 0x1FFFFFFF.
Additionally, from birthday paradox probability of collision in allowed TID range nears 50% after spawning 27000 threads. This is large but not totally impossible, thus replace random generation with sequential allocation.
pchickey requested abrown for a review on PR #7884.
This PR makes 0x1FFFFFFF the last TID that will be returned, but it is incorrect on wasm-libc because it reserves that for main thread ID. But wasi-threads proposal as written allows for this, so I'm not sure whether assume that's wasm-libc problem or limit it there 0x1FFFFFFE.
Milek7 edited a comment on PR #7884:
This PR makes 0x1FFFFFFF the last TID that will be returned, but it is incorrect on wasm-libc because it reserves that for main thread ID. But wasi-threads proposal as written allows for this, so I'm not sure whether assume that's wasm-libc problem or limit it here to 0x1FFFFFFE.
Milek7 deleted a comment on PR #7884:
This PR makes 0x1FFFFFFF the last TID that will be returned, but it is incorrect on wasm-libc because it reserves that for main thread ID. But wasi-threads proposal as written allows for this, so I'm not sure whether assume that's wasm-libc problem or limit it here to 0x1FFFFFFE.
Milek7 edited PR #7884:
TID returned by
wasi_thread_spawn
must be non-zero and upper three bits must always be zero: https://github.com/WebAssembly/wasi-threads?tab=readme-ov-file#design-choice-thread-idsCurrent implementation didn't fulfill this requirements, only clearing the top bit from random value. This breaks wasi-libc mutexes when random TID is larger or equal than 0x3FFFFFFF.
Additionally, from birthday paradox probability of collision in allowed TID range nears 50% after spawning 27000 threads. This is large but not totally impossible, thus replace random generation with sequential allocation.
Milek7 edited PR #7884:
TID returned by
wasi_thread_spawn
must be non-zero and upper three bits must always be zero: https://github.com/WebAssembly/wasi-threads?tab=readme-ov-file#design-choice-thread-idsCurrent implementation didn't fulfill this requirements, only clearing the top bit from random value. This breaks wasi-libc mutexes when random TID is larger or equal to 0x3FFFFFFF.
Additionally, from birthday paradox probability of collision in allowed TID range nears 50% after spawning 27000 threads. This is large but not totally impossible, thus replace random generation with sequential allocation.
abrown submitted PR review.
@Milek7, thanks for the PR!
abrown merged PR #7884.
Last updated: Dec 23 2024 at 12:05 UTC