Problems using objects created in main program from web worker or pthread

[Gregory Propf]

I'm experimenting with adding web workers and pthreads to my project. I've got some simple test code that attempts to modify objects defined in the global scope in a web worker or a pthread. 

When the code that modifies the object runs in the WW I get "_emval_take_value has unknown type d". My run_in_worker() function, where this error occurs, works fine as long as I call it directly. It's only when I attempt to post it to the worker that the binding error manifests.

In the pthread version it seems that some JavaScript val objects representing DOM elements for various html tags that are defined in the main thread do not get defined in the pthread. So we get "Cannot read properties of undefined (reading 'value')" when trying to modify them in the pthread. There are also some oddities about printf, cout, and console.log where some messages that have supposedly printed do not show up in the console output. Anyone know what all this is about and how to fix it?

[Sam Clegg]

On Wed, Nov 30, 2022 at 2:52 PM Gregory Propf <gpr...@gmail.com> wrote:

I'm experimenting with adding web workers and pthreads to my project. I've got some simple test code that attempts to modify objects defined in the global scope in a web worker or a pthread. 

When the code that modifies the object runs in the WW I get "_emval_take_value has unknown type d". My run_in_worker() function, where this error occurs, works fine as long as I call it directly. It's only when I attempt to post it to the worker that the binding error manifests.

I susect that embind simply doesn't work in wasm workers.  wasm workers are still new/experimental (is it ok to say that @juj?) and you may find features that don't work in wasm workers.

BTW you said web worker, but I think you mean wasm worker?  (An important difference).

 

In the pthread version it seems that some JavaScript val objects representing DOM elements for various html tags that are defined in the main thread do not get defined in the pthread. So we get "Cannot read properties of undefined (reading 'value')" when trying to modify them in the pthread. There are also some oddities about printf, cout, and console.log where some messages that have supposedly printed do not show up in the console output. Anyone know what all this is about and how to fix it?

The DOM only exists on the main thread, so you can't access anything DOM related on workers/pthreads.

Regarding standard output, I believe normal stdout (cout/printf) is proxied back to the main thread, so might not show up if your main thread is busy.   I believe that might also be true for console messages.  Under node we work around this by directly writing to stdout, but I don't know of any way to do that on the web platform.   Are you seeing messages completely disappear or just get delayed.

 

--
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/84bff0a5-53c6-46ee-9d39-f03f0cbf98can%40googlegroups.com.

[Gregory Propf]

I'm just using and slightly modifying the example code here - https://emscripten.org/docs/api_reference/wasm_workers.html?highlight=web%20workers, the "run_in_worker()" stuff. So I suppose that's wasm workers. If it's not a supported feature yet it's not that crucial. As for the pthreads DOM situation, I suspected that might be the problem. I just wanted to make sure it wasn't something I was doing wrong. I can get what I need from setTimeout() calls for iterating my simulation. I suppose If I was really determined I could have the thread or worker generate a JS event that would result in the GUI updating in the main thread. Or would that not be possible either?

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

[Jukka Jylänki]

My understanding is that embind would need to be initialized manually on each thread (wasm worker) context where it is supposed to be used? Might be that kind of initialization does not happen automatically with wasm workers.

Wasm workers certainly are a new feature, and there are probably blind spots there in what works well. I'd recommend building minimal test cases of things you do expect to work (that don't, but the documentation does not clearly illustrate why), and reporting them as bugs. Then either the documentation could be improved, or some issue could be fixed.

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