PROXY_TO_THREAD question

[Dieter Weidenbrück]

Hi,

I have a question about using -s PROXY_TO_THREAD=1.

My C code has 2 entry points:

int32_T main(int32_T argc,charPtr_T *argv){
//some initialisation
#ifdef __EMSCRIPTEN__
    emscripten_exit_with_live_runtime();
    return 0;
}

EMSCRIPTEN_KEEPALIVE
Error_T wasmEvent(int32_T evtType, int32_T nInt, float_T nFloat, void* param) {
//handling of all events coming in from JS
return 0;
}
Options used:

-s ALLOW_MEMORY_GROWTH=1 ^

-s ENVIRONMENT=web,worker ^

--shell-file ./index_template.html ^

-s SUPPORT_ERRNO=0 ^

-s MODULARIZE=1 ^

-sWASM_WORKERS ^

-pthread ^

-s PTHREAD_POOL_SIZE=1 ^

 -s PROXY_TO_PTHREAD=1 ^

-s "EXPORT_NAME='wasmMod'" ^

-s EXPORTED_FUNCTIONS="['_malloc','_free','_main']" ^

-s EXPORTED_RUNTIME_METHODS="['cwrap','UTF16ToString','UTF8ToString','stringToUTF8','allocateUTF8']" ^

-o index.html

When main is called
emscripten_is_main_runtime_thread() and
emscripten_is_main_browser_thread()

both return 0 as expected.
However, if I call wasmEvent from JS (using cwrap), they both return 1, so the code is not running in the same thread as main but rather in the main browser thread?

I can remember the first thread like this
mainThread = pthread_self();

and then use
emscripten_dispatch_to_thread(mainThread, EM_FUNC_SIG_VI, _wasmEvent, 0,(void*)&e, 0);
That does work, but I am unsure about the described behavior. I expected all code to run in the thread that ran main, except for specified pthreads created later.
What am I doing wrong?
Dieter

[Sam Clegg]

This is the expected behaviour of `-sPROXY_TO_PTHREAD`.   All this option does is proxy the main entry point of your program (main).   Any other events that arrive on the main thread (e.g. DOM events) would be run the main browser thread unless you proxy them over to another thread yourself.

cheers,

sam 

--
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/08f40bd0-3147-4a3c-a184-4aa40bde4987n%40googlegroups.com.

[Dieter Weidenbrück]

Thanks, Sam.
So PROXY_TO_PTHREAD makes sense only if I run some kind of loop inside main rather than waiting for events from the JS Side.
Thanks, I will handle this as described then.
Cheers,
Dieter

[Sam Clegg]

On Sun, Jul 30, 2023 at 1:55 PM 'Dieter Weidenbrück' via emscripten-discuss <emscripte...@googlegroups.com> wrote:

Thanks, Sam.
So PROXY_TO_PTHREAD makes sense only if I run some kind of loop inside main rather than waiting for events from the JS Side.

Yes, this option is mostly designed for the case where you have a long running `main` that would be a problem if it ran in the main browser thread.   In this case, you can choose from a few options such as splitting up your `main` function or using `PROXY_TO_PTHREAD` to have it run on another thread.

cheers,

sam

Thanks, I will handle this as described then.
Cheers,
Dieter

--

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/3afe4fde-2def-41e3-b4f2-053c8c8452a3n%40googlegroups.com.

[Dieter Weidenbrück]

Understood, thanks. So PROXY_TO_THREAD doesn't make sense for my usecase.

All I want to do is

- draw WebGL content in one thread (could be the main thread because rendering doesn't need much time, and there is no animation loop)

- do some work in the background that makes use of the same canvas including the uploaded geometry for depth calculations

I am struggling to find the right way through all the context and proxy options. Any suggestions would be very welcome. The test cases are helpful, however, I wasn't able to find one that passes back and forth control over the same canvas between a thread and the main thread.

[Jukka Jylänki]

> I wasn't able to find one that passes back and forth control over the same canvas between a thread and the main thread.

This is something that web browsers do not natively support.

A canvas is accessible from the main browser thread, and from a Worker only if using the OffscreenCanvas feature. But it cannot be accessed from both simultaneously, or access quickly switched between Worker and a main thread.

One model might be to build with -pthread, and then do rendering on the main browser thread, and then pthread_create() a background computation thread, and then have the background computation thread send a message to the main browser thread to pull whatever data it needs from the canvas over to the background pthread. This message sending can be implemented manually, or by using Emscripten's foo__proxy: 'sync' JS directives.

Another model would be to build with -pthread -sOFFSCREEN_CANVAS, and then create the rendering context in one worker, and the background computation thread in another worker. Then you can use possibly faster synchronization primitives to ask data from the rendering thread over to the background thread, since the main browser thread cannot synchronously wait to receive any messages, only Workers can.

--
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/a36c042f-3b33-4f52-ad18-75ca480394e7n%40googlegroups.com.

[Dieter Weidenbrück]

JJ,

thanks for your recommendation, that was extremely helpful. For now I am using the first approach but will possibly try the second one as well to further reduce blocking time on the main thread.