Thread-Local Variable Destructors

[daxpedda]

I was wondering what the plans are for thread-local variable destructors in Wasi, is this in scope at all?

Typically something like __cxa_thread_atexit would be necessary.

[sbc100]

I think this would be part of wasi-sdk, as part of its support for C++ in general. I don't think there should be any need for the wasi-threads proposal to include specific support for this.

[daxpedda]

Well wasi-sdk is for C++, I'm interested in Rust in this case.
Would https://github.com/WebAssembly/tool-conventions be the right place to figure this out then?

[sbc100]

With C++ its up to clang to generate __cxa_thread_atexit calls and then its up the libc++ to implement __cxa_thread_atexit. I don't think we should need to tool convention since the C++ standard already defines this and I don't think we need to do anything special.

Does rust support wasi-threads yet? Does it build on top of wasi-libc's pthread support to try to roll it own? If it rolls its own then it sounds like it just be matter of implementing __cxa_thread_atexit. If it builds on wasi-libc (which I believe would be the sensible thing to do) then it would "just work" once we have support in wasi-libc/libc++

[daxpedda]

Does rust support wasi-threads yet?

Not as far as I know.

Does it build on top of wasi-libc's pthread support to try to roll it own?

It's using wasi-libc.

If it rolls its own then it sounds like it just be matter of implementing __cxa_thread_atexit.

I think this is where the crux of the issue is. Different languages need to coordinate a single place to call __cxa_thread_atexit from. If you have a C++ application, and you are pulling in a Rust library that creates some thread-local variables, Rust shouldn't use it's own __cxa_thread_atexit, because it doesn't know when the thread will get dismantled.

I don't know the details here, but in this specific case it might not matter, because if both C++ and Rust are using wasi-libc they might be calling the same __cxa_thread_atexit anyway.

In any case, it might be useful to make everybody agree on a single place to call __cxa_thread_atexit from.

(My original motivation isn't Wasi but Wasm, which faces the same problem, but doesn't have a corresponding wasi-libc. So I thought it's probably best to figure out what Wasi does in this case as they actually have a specification to spawn threads, which Wasm doesn't.)

[abrown]

@daxpedda, last year we got approval to add a new target, wasm32-wasi-threads, to rustc: rust-lang/compiler-team#574. The plan that some of us discussed at the time was to reuse wasi-libc to implement Target::new in Rust's standard library. I believe wasi-libc is already in use for the wasm32-wasi target in rustc so it made sense to use the threads-enabled wasi-libc as well. If that plan were implemented, it seems to me that @sbc100 is right in that this issue is probably resolved:

If it builds on wasi-libc (which I believe would be the sensible thing to do) then it would "just work" once we have support in wasi-libc/libc++

Why hasn't this been done already? Well, I would like to get to this task but have been busy with other work. My sense is that parts of this would be straightforward but we might discover, by digging into the code, some issues that could be bigger (e.g., spec or tool conventions). @daxpedda, are you interested in working on this? We can chat more on Zulip if you would like to discuss more.