Consider adding thread teardown helpers

[jrvidal]

👋 hi, I work on Stackblitz, where we heavily rely on wasm-bindgen and threads ❤️

However, we're being hit pretty hard by the lack of thread teardown routines. Unlike other use cases, we don't spawn a fixed number of threads. Instead, we spawn workers on demand, roughly corresponding to user-created "processes". This means that a long-running project ends up leaking at least 1MiB of thread stack only [*], without counting TLS, per process 😱

We've perused the open issues and existing discussions (mostly this) and we realize there is not clear runtime model for proper thread support. But we could greatly benefit if wasm-bindgen exposed a helper to clean up the thread stack, even in the most hacky and unstable way. We have done a little experimentation on our side and it doesn't seem like a huge change, we could happily submit a PR.

We understand this is far from an ideal solution, but without something like this, our only option will pretty much be using a private fork 😞

Thoughts?

[*]: though yes, we're looking into reducing the pre-allocated stack size to alleviate the issue.

[alexcrichton]

Thanks for the report, and yes this is something that was never designed because it didn't really make sense at the time. I never got around to doing this because it never felt like the right way to implement things and the whole wasm-on-threads-on-the-web story seemed under-baked. Not to say that this can't be done, it's not like the threading support in wasm-bindgen isn't already very wasm-bindgen and/or Rust specific.

Otherwise the main issues AFAIK are TLS destructors and deallocation of the stack. Especially deallocation of the stack around synchronizing what stack free runs on I think will be particularly tricky.

I can try to help out to review patches if you'd like to upstream support.