Sam Clegg

Some kind of API like JS's `navigator.hardwareConcurrency` would make sense to me, but I don't think that should be the upper limit of the number of threads that can be...

I don't think "maximum number of threads spawn-able" is very useful, or practical to implement. It doesn't map to any underlying OS primitive that I know of. I guess it...

As a reference point, emscripten has been shipping multi-threaded apps based on workers (instance-per-thread) for a while now, and the shared memory is always imported by the module in this...

Interesting point regarding cleanup. Presumably `pthread_exit` could do any needed cleanup prior to calling `wasi_thread_exit`. Anyone who calls `wasi_thread_exit` is going underneath the pthread abstraction and therefore perhaps its reasonable...

Note that we could consider not supporting `pthread_exit` at all. IIUC C++ thread API has not way to exit a thread early, unlike pthreads (pthread_exit) and C11 threads (https://en.cppreference.com/w/c/thread/thrd_exit). I'm...

I don't think `wasi_proc_exit` should be used to implement `pthread_exit`.

@loganek do you think being able to exit a thread without unwinding the stack is critical? What do you think about simply not implementing `pthread_exit` at all?

Can you explain a little more why you have concerns about `a-1`? It seems like the most obvious solution to me. I'm not sure what you mean by "non wasi-threads...

Based on how many programs seems to depend on `pthread_exit` I'm leaning towards adding `wasi_thread_exit`. Is there anyone who feels strongly that we should *not* add it?

In emscripten we have found it useful to be able to do bounds checking in userspace. For that, we use binaryen pass which we run over the compiled module: https://github.com/WebAssembly/binaryen/blob/main/src/passes/StackCheck.cpp....