Remove thread IDs

[Amanieu]

Thread IDs are a design mistake and many OSes are moving away from them (e.g. pidfd on Linux, HANDLE on Windows). The main issue is that the lifetime of a thread ID is tied to the lifetime of a thread: if a thread exits, the thread ID can be reused for another thread.

The main motivation for host-generated thread IDs is to allow these to be used with hypothetical future WASI syscalls such as thread_setpriority. A better way to support this would be to have wasi_thread_spawn return a thread handle instead of a thread ID. The main differences are:

• The lifetime of a thread handle is independent of the thread it is referencing: it is possible to have a handle referring to a thread that has exited.
• A handle can be cloned and closed, just like a file descriptor. In fact this could even be implemented as a special kind of fd and reuse the existing fd management syscalls.

If a unique thread ID is still required for internal use (e.g. futexes) then this should be allocated by wasi-libc using an atomic counter (for example) and passed to wasi_thread_spawn as part of the thread's initial state. There is no need to get the host involved in this. wasi-libc can keep a thread handle in pthread_t for any syscalls that require a thread handle.

[SamuraiCrow]

I agree. Having a thread close and another reopen with the same ID sounds like a race condition just waiting to happen.

[penzn]

I think for the Web thread handle can be a reference to Worker object.

[yamt]

Thread IDs are a design mistake and many OSes are moving away from them (e.g. pidfd on Linux, HANDLE on Windows). The main issue is that the lifetime of a thread ID is tied to the lifetime of a thread: if a thread exits, the thread ID can be reused for another thread.

The main motivation for host-generated thread IDs is to allow these to be used with hypothetical future WASI syscalls such as thread_setpriority. A better way to support this would be to have wasi_thread_spawn return a thread handle instead of a thread ID. The main differences are:

* The lifetime of a thread handle is independent of the thread it is referencing: it is possible to have a handle referring to a thread that has exited.

* A handle can be cloned and closed, just like a file descriptor. In fact this could even be implemented as a special kind of fd and reuse the existing fd management syscalls.

If a unique thread ID is still required for internal use (e.g. futexes) then this should be allocated by wasi-libc using an atomic counter (for example) and passed to wasi_thread_spawn as part of the thread's initial state. There is no need to get the host involved in this. wasi-libc can keep a thread handle in pthread_t for any syscalls that require a thread handle.

i'm not sure what's the motivation. even today, wasi-libc pthread_t can point to the exited thread without problems.