App is freezing in OffscreenCanvas.getContext("2d").getImageData !

[aharondavid]

See the comment in the code below:

unsigned int futexVal = 0;

void* WakingThread(void* arg)
{
	Sleep(1000);
	using namespace emscripten;
	val offscreen = val::global("OffscreenCanvas").new_(256, 256);

	val context3 = offscreen.call<val>("getContext", std::string("2d"));

///////////////////////////////////////////////
  // After that line, the App freeze ! it seem to me a dead lock !
  // Without this line everything is ok.

      val imageData = context3.call<val>("getImageData", 0, 0, 50, 50);
/////////////////////////////////////////////////

``
	emscripten_atomic_store_u32(&futexVal, 1);
	emscripten_futex_wake(&futexVal, INT_MAX);

	pthread_exit(0);
}

// the main()  run in main thread
OnButton()
{        
        pthread_t thread;
	pthread_attr_t attr1;
	pthread_attr_init(&attr1);
	int rct = pthread_create(&thread, &attr1, (void* (*)(void*))WakingThread, nullptr);
	
	while (emscripten_atomic_load_u32(&futexVal) == 0)
	{
		emscripten_console_log("in __");
		emscripten_futex_wait(&futexVal, 0, INFINITY);
		emscripten_console_log("end __");
	}
}

Version of emscripten/emsdk:
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.9 (54675ba)
clang version 15.0.0 (https://github.com/llvm/llvm-project faef447e72a5c63dfb12bb7b02d44c3c916d31cd)
Target: wasm32-unknown-emscripten
Thread model: posix

[sbc100]

Are you setting either PROXY_TO_PTHREAD or PTHREAD_POOL_SIZE? (can you can include your full link time it would help us diagnose you issues). If you don't specify either of these flags then you cannot start using your newly created threads until you return the even loop. See https://emscripten.org/docs/porting/pthreads.html#special-considerations for more details.

[aharondavid]

yes. I had set PTHREAD_POOL_SIZE , but the code above is run OnButton is pressed (code above fixed).
and OnButton pressed we are, by sure, after event loop called.

here is the full link flags command:
-s WASM_BIGINT -s OFFSCREEN_FRAMEBUFFER=1 -s OFFSCREENCANVAS_SUPPORT=1 -g --preload-file com.skyline.terraexplorer --bind -s USE_PTHREADS -s ALLOW_MEMORY_GROWTH=1 -s EXPORTED_RUNTIME_METHODS=ccall,cwrap -s EXPORTED_FUNCTIONS=_openFly,_main,_CreateTE4WEB -s PTHREAD_POOL_SIZE=30

[sbc100]

Is there any reason you are using the low level mutex API.. why not use pthread_cond_wait?

[aharondavid]

I started from pthread_cond_wait but I got the same behavior.
additional, according to Emscripten Pthread document, we can't use pthread_cond_wait in the main thread

[sbc100]

You can use emscripten_futex_wait and pthread_cond_wait on the main thread, but they block the UI so should not be done for very lock. (internally they both busy wait on the main thread).

The restrictions on the main thread are the same for pthread_cond_wait and emscripten_futex_wait (internally pthread_cond_wait uses emscripten_futex_wait).

[sbc100]

Can you confirm if WakingThread even starts... i.e. are you sure its blocking in getImageData?

[aharondavid]

yes, I am sure. I verified in debug.
also, as I already wrote, without the getImageData the code above is work

[sbc100]

Do presumably the main thread needs to return to even loop in order to allow getImageData to proceed.

Can you confirm this? i.e. if you return the event loop does futexVal get stored to as expected? (i.e return from the OnButton function rather than busy waiting?)

@juj would you expect getImageData to require the main event loop to be running?

[aharondavid]

it work after return to event loop, but the point is that I must to wait for the thread before returning to event loop.
I though that the busy wait is a solution for that case.

[aharondavid]

getImageData is not the only case, my assumption is that every function that access to the main thread, in the above code, will stuck.
So, i think that there is a problem in busy wait machnize

[aharondavid]

As I understand ,that in some cases busy wait is not an option. One of them is getImageData.
Instead, we should to return to the event loop.
Is it true?
If so, It is put our Emscripten project in question mark ☹️

[juj]

@juj would you expect getImageData to require the main event loop to be running?

This is possible, and given the complexity of Canvas & WebGL & OffscreenCanvas API, also somewhat likely.

Unfortunately none of the web browser specifications define any of this behavior, as it is something that has caught the web ecosystem "off guard": prior to SharedArrayBuffer none of the browser internal proxying mechanisms would have been observable, but after SAB arrived, the fact that some Worker-based web APIs require synchronous assistance from the main thread to work is now visible.

The only way to fix this is to avoid ever blocking the main thread, but let it regularly yield back to the event loop (i.e. remove the while (emscripten_atomic_load_u32(&futexVal) == 0) loop on the main thread)

[aharondavid]

Removing the while (emscripten_atomic_load_u32(&futexVal) == 0)
Does’t help, if you run the code above, you will see that you will not get to the line after
escripten_futex_wait.
I thought that the busy wait do return to event loop, isn’t it?