[threading] variable has incomplete type 'em_queued_call' (aka 'struct em_queued_call')

[Soeren Balko]

Returning back to WASM multi-threading after COOP/COEP put a spanner in the works when I last tried it. Unfortunately, the Emscripten toolchain has much changed since I last managed to compile a multi-threaded build. 

Specifically, I am running into what looks like a trivial problem. This code won't compile:

#include <emscripten/threading.h>

#include <stdio.h>

static void a(int arg) {

    printf("Hello %i\n", arg);

 }

int main(int argc, char **argv) {

   em_queued_call q = {

       .functionEnum = EM_FUNC_SIG_VI,

       .functionPtr = a

    };

    q.args[0].i = 42;

    emscripten_sync_run_in_main_thread(&q);

}

Specifically, the struct em_queued_call is only partially defined (as per emscripten/threading.h), where the full definition (in threading_internal.h) is not included.

I am compiling like so:

emcc -pthread test.c

Doesn't get any simpler. I remember this worked with an old Emscripten version 1.XX, but no more. 

Any ideas?
Soeren

[Soeren Balko]

As a follow up: is using the em_queued_call struct discouraged in favor of using emscripten_sync_run_in_main_runtime_thread,  emscripten_async_run_in_main_runtime_thread & friends? It would like seem this way...

[Mark Sibly]

I've been using emscripten_async_run_in_main_runtime_thread for 6 months or so now and it works great for me.

I do feel this stuff needs to be better docced, emscripten.org has nothing about threading in the API reference section, I feel like there should at least be a 'threading.h' page in there? There's some useful stuff in 'Wasm Workers API' (that's where searching for emscripten_async_run_in_main_runtime_thread takes me) although I've need used a 'Wasm Worker' so this feels like the wrong place to be looking for info on threading.

Bye!
Mark

[Thomas Lively]

It looks like there was some unintentional breakage of `emscripten_sync_run_in_main_thread` in December. I left a comment on the relevant PR: https://github.com/emscripten-core/emscripten/pull/15756#issuecomment-1400603196.

That being said, the best way to send work to other threads these days is using the proxy queue mechanism in proxying.h. These new APIs are safer to use to proxy nontrivial work, give you more control over when work is executed, and give you more control over how you wait for the work to be done. FWIW, the older `emscripetn_async_run_in_main_thread` and other proxying APIs in threading.h have been internally reimplemented in terms of proxying.h as well.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/3b303b63-4008-49f0-bb8b-f48a8c0b294fn%40googlegroups.com.

[Sam Clegg]

I think the solution is to use the `emscripten_sync_run_in_main_runtime_thread` family of functions.  I've opened a PR to remove the (as you point out, currently unusable/broken) `emscripten_sync_run_in_main_thread` family.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EUaJ%2BWiBT2abCVscMm5WXAGJ35g8jk8p1qOobiGF%3DjKJw%40mail.gmail.com.

[Soeren Balko]

Thanks for responding - I will take a look at the new features provided by proxying.h. That header didn't exist when I last looked into Emscripten's multi-threading support. The emscripten_(a)sync_run_in_main_runtime_thread functions work equally well for me at this point.