Calling into worker via embind with PROXY_TO_PTHREAD=1 attempts to call GL functions on the main thread

[sasmaster]

Hi.
After not receiveing any answer in the "Issues" list I am asking for help with this problem here.

I am writing a rendering app. I need it to run in a secondary thread in order not to interfere with UI.
My linker config is as follow:

-sINITIAL_MEMORY=134217728 -sMAX_WEBGL_VERSION=2 -sWASM=1 -sFULL_ES3 -sASYNCIFY -sPROXY_TO_PTHREAD=1 -sOFFSCREEN_FRAMEBUFFER=1 -sOFFSCREENCANVAS_SUPPORT=1 -sNO_EXIT_RUNTIME=1 -lembind -sENVIRONMENT=web,worker -sUSE_PTHREADS=1 -sPTHREAD_POOL_SIZE=8 -lpthread -msimd128 -matomics -mbulk-memory

Inside my app I am creating webgl2 context with the following attributes:

attrs.explicitSwapControl =  EM_TRUE;
attrs.renderViaOffscreenBackBuffer = EM_FALSE;
attrs.enableExtensionsByDefault = EM_TRUE;
attrs.premultipliedAlpha = EM_TRUE;
attrs.preserveDrawingBuffer = EM_FALSE;
attrs.proxyContextToMainThread = EMSCRIPTEN_WEBGL_CONTEXT_PROXY_DISALLOW;

I am not sure about the second one but it is probably not related to my problem.
Now, I have a function called Init() and Run(). Init() creates webgl context and makes it current. Run() creates renderable objects and launches render loop with emscripten_set_main_loop_arg(&Render, this, 0, 1);

If Run() gets called within the app, like this:

  int main(int argc, char* argv[])
{
	if(!app.Init())
	{
		return EXIT_FAILURE;
	}
	app.Run();
	return EXIT_SUCCESS;
}

It all works, Stuff is rendering.
However,I need this function to be called via button press on the front end. For this I am using embind to expose the function to JS.
If I call Run() via JS it looks like the webgl context gets lost. Also in the callstack I can see that the code tries to execute the function on the main thread. And my context lives in the worker thread.

WasmApp.js:4923 Uncaught TypeError: Cannot read properties of undefined (reading 'bindFramebuffer')
    at _glBindFramebuffer (http://localhost:5500/WasmApp.js:4923:9)
    at imports.<computed> (http://localhost:5500/WasmApp.js:3042:20)
    at WasmApp.wasm._do_call (http://localhost:5500/WasmApp.wasm:wasm-function[1417]:0x6fd54)
    at WasmApp.wasm.maybe_call_on_current_thread (http://localhost:5500/WasmApp.wasm:wasm-function[1416]:0x6f037)
    at WasmApp.wasm.do_dispatch_to_thread (http://localhost:5500/WasmApp.wasm:wasm-function[1412]:0x6ebd2)
    at WasmApp.wasm.emscripten_async_run_in_main_thread (http://localhost:5500/WasmApp.wasm:wasm-function[1418]:0x71cae)
    at WasmApp.wasm.emscripten_async_run_in_main_runtime_thread_ (http://localhost:5500/WasmApp.wasm:wasm-function[1423]:0x725f7)
    at WasmApp.wasm.glBindFramebuffer (http://localhost:5500/WasmApp.wasm:wasm-function[1260]:0x6172f)
    at WasmApp.wasm.WebApp::Run() (http://localhost:5500/WasmApp.wasm:wasm-function[1238]:0x5f746)
    at WasmApp.wasm.emscripten::internal::MethodInvoker<emscripten::internal::rvp::default_tag, void (WebApp::*)(), void, 

From what I understood in the docs, embind should work fine with worker proxing function calls into the worker thread. But here it doesn't look like that. It seems like embind is attempting to execute the function on the main thread, which is not what I want.
Can someone explain what's going on here? And if embind is not supposed to work in this mode, what is the alternative for setting a communication between this wasm app and JS?
Thanks.

[sbc100]

When you build with -sOFFSCREENCANVAS_SUPPORT it looks like all gl calles (e.g. glBindFramebuffer) are conditionally proxied back to the main thread.

For glBindFramebuffer see

emscripten/system/lib/gl/webgl1.c

Line 133 in 4b76531

ASYNC_GL_FUNCTION_2(EM_FUNC_SIG_VII, void, glBindFramebuffer, GLenum, GLuint);

This definition uses ASYNC_GL_FUNCTION_2 which is defined here:

emscripten/system/lib/gl/webgl_internal.h

Line 26 in 4b76531

#define ASYNC_GL_FUNCTION_2(sig, ret, functionName, t0, t1) ret functionName(t0 p0, t1 p1) { GL_FUNCTION_TRACE(); if (pthread_getspecific(currentThreadOwnsItsWebGLContext)) emscripten_##functionName(p0, p1); else emscripten_async_run_in_main_runtime_thread(sig, &emscripten_##functionName, p0, p1); }

This looks like the function will run on the worker thread if pthread_getspecific(currentThreadOwnsItsWebGLContext) otherwise it will get proxied back to the main thread.

I'm not sure that will solve your problem but it might help you debug?

[sbc100]

No, ASYNC_GL_FUNCTION_2 is used to build libwebgl which then takes case of the proxying for you.

The reason the proxying is happening is because pthread_getspecific(currentThreadOwnsItsWebGLContext) is returning false, which means that current thread doesn't think that it owns its own webgl context. Do you expect the thread to have own its GL context?

[sasmaster]

" Do you expect the thread to have own its GL context?" - of course. PROXY_TO_PTHREAD=1 runs the whole WASM in a worker. And I am making the WEBGL context current on the main thread in the WASM whereas that "main thread" is actually a worker thread. And when I am triggering a function which calls GL API via embind,I can see it is happening on the real main thread, and there is no GL context set current there.

[sasmaster]

And how I know the context is current and is working? If I run the rendering calls as a part of the app flow (not via external function calls) it all works fine.

[sbc100]

And when I am triggering a function which calls GL API via embind,I can see it is happening on the real main thread, and there is no GL context set current there.

That is the likely the problem then. You are trying to do rendering on them main browser thread, but the GL which does not have an active GL context. Is that hope that these calls will be proxied to the PROXY_TO_PTHREAD thread?

[sasmaster]

Kind of, I am not sure. The only source of info that assured me that embind would rout the calls into the worker thread was ChatGPT.

[sbc100]

Wait, actually I don't see any proxying happening. emscripten_async_run_in_main_thread ends up calling maybe_call_on_current_thread and the logic there is deciding the that the target thread is the current thread:

emscripten/system/lib/pthread/proxying_legacy.c

Lines 364 to 367 in a9e18d8

	if (pthread_equal(target_thread, pthread_self())) {
	_do_call(call);
	return 1;
	}

This means that I think Run is being called from the main runtime thread, not from the proxied main. Are you sure that the backtrace you shared is from the proxied main thread? It looks like the Run is coming from at WasmApp.wasm.emscripten::internal::MethodInvoker<emscripten::internal::rvp::default_tag, void (WebApp::*)(), void, which looks like maybe and embind call? Could it be that is happening on the main browser thread?

[sasmaster]

Could it be that is happening on the main browser thread? - that's exactly what I believe is going on,otherwise it 's hard to explain why GL API calls fail. Look, if I call Run() in code - all works well. Once I call it via embind call, I am getting GL calls crashes. Seeing emscripten_async_run_in_main_thread in the call stack makes me think that the calls are triggered on the real main thread. So what I want to know is if it is possible to have embind calls executing in the proxied main thread. And if it is possible, then how?

[sbc100]

You would need to somehow proxy that work to the thread that is running main. There are various proxying mechanism available in emscripten. The most explicit one is defined in https://emscripten.org/docs/api_reference/proxying.h.html.

IIUC there is no simple way to proxy JS calls to a background thread without calling into native code first.