Why is startup of a WASM worker asynchronous?

[msqr1]

Couldn't you instantiate the WASM and do literally everything else synchronously in a worker? It's the same as a pthread startup, isn't it?

[juj]

It is asynchronous mainly because of this web browser limitation.

Fortunately that limitation has been regarded to be a browser bug, and it is getting resolved in newer browsers. If you are running in a browser that has the above bug fixed, you can treat Wasm Worker creation to be as if it was synchronous, just like pthread_create().

[msqr1]

Since the wasm workers are supposed to be light, and now that it can startup synchronously, we should remove the delayed function queue for reduced size.

Another suggestion: the xxx_post_function_xxx api is really bad (post_function_sig isn't even usable because you can't convert function pointers to void pointers).

Perhaps for wasm workers we could change that into a std function and have just one post function.

If std function is too heavy, we could make one single post_function template, and use code over in embind to build the signature string, with va_args or variadic template for arguments

Better yet, we should just remove it altogether, and let user provide a main loop function in the worker constructor (just like set_main_loop) where they do synchronization themselves so we can just get rid of the queues altogether. We only do the bare minimum of instantiating the wasm in the worker and run the provided function once in thus case

[juj]

PRs to improve are welcome. Note that Wasm Workers is a stable API, so cannot remove anything to break users, and it is also a C-facing API, so anything requiring C++ cannot be baked into the API. An additional C++ layer to add std::function support could work, for example.