Add canvas transfer API for next thread

[stevennyman]

Useful for thread creation APIs such as std::thread or boost::thread that do not let you pass a pthread_attr_t and therefore cannot use emscripten_pthread_attr_settransferredcanvases() for transferring canvases. Fixes #10307.

The APIs added to <emscripten/threading.h> are emscripten_set_next_thread_transferredcanvases(const char* str) and emscripten_get_next_thread_transferredcanvases(const char** str). This PR also adds a test case and documentation.

(Note: I worked with an LLM while preparing this PR and made adjustments as needed.)

[stevennyman]

Following up since it's been some time

[kripken]

Seems reasonable to me. @sbc100 @juj any thoughts?

[sbc100]

Seems a little clunky.. but maybe there not a more elegant way to do this?

How about providing a way to transfer canvas after thread creation?

[stevennyman]

Seems a little clunky.. but maybe there not a more elegant way to do this?

How about providing a way to transfer canvas after thread creation?

Based on #10307 (comment) it appears that it might not be straightforward to implement canvas transfer methods after thread creation unless there have been changes since that comment was made.

[stevennyman]

CI failures seem to be for unused variables in parts of the codebase not modified by this PR. I'm not sure why.

[juj]

Hmm, does this actually work?

Remember: all thread creation are proxied to the main thread under pthreads. This is (among other things) because there are no nested Worker/thread creation.

So, if main thread (or some other thread) is calling

emscripten_set_next_thread_transferredcanvases("mycanvas");
std::thread thr(thread_start); // intended to get 'mycanvas'

and another thread happens to race, to also create a thread

std::thread thr(another_thread_start);

then because the thread creation is proxied, and pthread cancellation points (the points at which the proxying system checks if another thread has a pending proxy request) can occur inside std::thread ctor (say, if its internal implementation reads I/O, or calls any shared state/mutex function), it could happen that it is actually another_thread_start that will be the next thread to be created, and receive the transferred canvas, and not the thread_start thread.

The original transferred offscreen canvases mechanism was intended to help portability without code changes, in scenarios where the exact same code should run in the ported codebase. (when users cannot afford to change code)

Here in this PR, this proposed new function probably does not fall under those constraints? So solving this by code changes to the user project would be ok?

In juj/wasm_webgpu, I created a "userland" mechanism to transfer a canvas to a thread: https://github.com/juj/wasm_webgpu/blob/8063d5373eeefac5e627c6830681e71acc4a9f35/samples/offscreen_canvas/offscreen_canvas_pthread.c#L37-L56 . I think this is a more natural "web-native" way to pass a canvas to a pthread (or a Wasm Worker).

That code should work for std::thread with the std::thread::native_handle() functionality.

The idea there is to first create the thread, and then have a separate API to pass the OffscreenCanvas to that already created thread.

If you want to integrate with the existing WebGL mechanism, then a bit of extra JS library code will be needed to inject the transfered canvas to GL.offscreenCanvases map, though should be straightforward.

The JS side code for the above sample lives at https://github.com/juj/wasm_webgpu/blob/8063d5373eeefac5e627c6830681e71acc4a9f35/lib/lib_webgpu.js#L2604-L2711 to give an idea.

Can you give the above a peek - would that solve the usage here instead?

[stevennyman]

Thanks @juj for the pointers and the examples. The idea of creating JS functions to use from C and setting up a pthread by first pointing it to a dummy function while sending the canvas sounds like a reasonable solution and it seems like it should theoretically be somewhat straightforward to implement as well; it seems like hopefully the other thread would pick it up if I set GL.currentContext. I'll look into this.