Reserve some TID values #16
Conversation
discussion: WebAssembly#15
|
|
||
| * TID 0 is reserved. `wasi_thread_spawn` should not return this value. | ||
|
|
||
| * The upper-most 3-bits of TID are always 0. |
There was a problem hiding this comment.
note:
- the upper-most 2 bits are to meet the current assumptions in wasi_thread_spawn and wasi-libc.
- another bit is intended for __init_tp: Initialize TID to non-zero value wasi-libc#360 and similar usage.
There was a problem hiding this comment.
Could you explain in the document why is that a requirement?
There was a problem hiding this comment.
Also, I'm not sure if the proposal should be driven by the current implementation of it in other libraries; I think it should be other way around - unless it really makes sense to keep it like that.
There was a problem hiding this comment.
i think it really makes sense to avoid rewriting tid-based locking in musl.
There was a problem hiding this comment.
Could you explain in the document why is that a requirement?
done
|
@abrown, I was going to add you as a reviewer but I don't seem to have permission. How do you feel about adding me as a contributor? |
README.md
Outdated
| locking implementation in musl/wasi-libc. | ||
|
|
||
| * The third bit need to be 0 in order to make an extra room for other | ||
| reversed values in wasi-libc. |
There was a problem hiding this comment.
| reversed values in wasi-libc. | |
| reserved values in wasi-libc. |
There was a problem hiding this comment.
oops, fixed. thank you
There was a problem hiding this comment.
I'm fine with adding something like this to the specification, though I may be tempted to rewrite this a bit to make it a bit more clear. I think those of us doing implementation of wasi-threads should be thinking whether more bits than 3 will need to be reserved.
|
is there anything blocking this? |
|
Do apologize, I was on holiday and still catching up on various threads. I'm ok with that change. |
This fixes TID-based locking used within libc. Also, initialize detach_state. cf. WebAssembly/wasi-threads#16
According to the [WASI thread specification](WebAssembly/wasi-threads#16), some thread identifiers are reserved and should not be used. In fact, only IDs between `1` and `0x1FFFFFFF` are valid. The thread ID allocator has been moved to a separate class to avoid polluting the `lib_wasi_threads_wrapper` logic.
This fixes TID-based locking used within libc. Also, initialize detach_state. cf. WebAssembly/wasi-threads#16
This fixes TID-based locking used within libc. Also, initialize detach_state. cf. WebAssembly/wasi-threads#16
According to the [WASI thread specification](WebAssembly/wasi-threads#16), some thread identifiers are reserved and should not be used. In fact, only IDs between `1` and `0x1FFFFFFF` are valid. The thread ID allocator has been moved to a separate class to avoid polluting the `lib_wasi_threads_wrapper` logic.
discussion:
#15