[Development] Wasm: Support for Emscripten PROXY_TO_PTHREAD?

[Stephan Bergmann]

On 06.12.24 16:49, Morten Sørvig wrote:
> On 5 Dec 2024, at 10:49, Stephan Bergmann <sberg.fun at gmail.com> wrote:
>> We need Emscripten's -sPROXY_TO_PTHREAD setting, which moves the 
>> application's main thread off the browser main thread into a pthread, 
>> to which it transfers any canvas DOM element as an OffscreenCanvas 
>> upfront).  We need that, among others, because the LibreOffice code 
>> wants to arbitrarily spawn further threads from within event loop 
>> callbacks, something that would run into deadlocks without - 
>> sPROXY_TO_PTHREAD.
> 
> This sounds like the (known) issue where blocking the main thread can 
> prevent the browser from servicing the secondary thread, and deadlock. 
> If you can avoid this then starting threads should work, so it might be 
> worth revisiting.
> 
> In particular calling pthread_join() can prevent the browser from 
> creating a web worker for the thread, which is for sure a deadlock (I 
> don’t know what the LibreOffice code looks like here, though).

There's unfortunately not really a reasonable hard upper limit value for 
-sPTHREAD_POOL_SIZE= we could set.  (And besides, spawning new threads 
is just one thing that would benefit from -sPROXY_TO_PTHREAD; e.g., the 
networking scaffolding described at 
<https://emscripten.org/docs/porting/networking.html> needs it to, and 
in general the Emscripten restrictions appear to make it an attractive 
move overall to be able to build with -sPROXY_TO_PTHREAD.)

>> So, my question is what the general opinion here is regarding support 
>> for Emscripten's -sPROXY_TO_PTHREAD in today's Qt 6.  Has this been 
>> discussed before?  Is it considered something that you wouldn't want 
>> to support, or something that would be supported if somebody set out 
>> to actually implement it, or…?
> 
> There has been some discussions, although no serious efforts at 
> implementing it. The question would be if this be implemented in  a non- 
> obtrusive (or not-too-obtrusive) way in Qt. Typical native API usage can 
> look like
> 
>    emscripten::val rect = 
> m_window.call<emscripten::val>("getBoundingClientRect");
>    emscripten::val top = rect["top"].as<qreal>();
> 
> In theory val::call() (or a wrapper) could proxy to the browser main 
> thread, and return a DOMRect moved to the proxy thread. I think we don’t 
> want to wrap all of the individual API usage sites in 
> emscripten_async_run_in_main_runtime_thread().
> 
> Would it be better to implement this in Emscripten itself? There is 
> https://github.com/emscripten-core/emscripten/issues/9847 <https:// 
> github.com/emscripten-core/emscripten/issues/9847>, but it was closed.
> 
> First steps could be to create a prototype which demonstrates that the 
> approach can work, and shows what the code would look like.

Yeah, getting something in in a non-ad-hoc and mostly non-obtrusive way 
is what gave me a hard time with my experiments, and made me give up for 
now.  But maybe I'll eventually muster some more courage and revisit... 
Anyway, thanks for your response!