[Development] Wasm: Support for Emscripten PROXY_TO_PTHREAD?

[Stephan Bergmann]

Hi all,

We are leveraging Qt's fine Wasm/Emscripten platform support in a 
project where we compile LibreOffice with Emscripten to run in the 
browser (see <https://zetaoffice.net/>).  We are currently based on a 
slightly patched, old Qt 5.15.2 version (see 
<https://github.com/allotropia/qtbase/tree/5.15.2%2Bwasm>).

We need Emscripten's -sPROXY_TO_PTHREAD setting (see 
<https://emscripten.org/docs/tools_reference/settings_reference.html#proxy-to-pthread>, 
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.

Qt does not appear to support -sPROXY_TO_PTHREAD out of the box.  But 
for that old Qt 5.15.2, it was relatively easy to patch things up: 
There was only a single qtcanvas DOM element, so Emscripten can be 
instructed to transfer it with -sOFFSCREENCAVNASES_TO_PTHRAD=#qtcanvas. 
And Qt code that accessed browser functionality that is only available 
on the browser's main thread (so cannot be accessed directly any more 
with -sPROXY_TO_PTHREAD) was relatively rare, and I patched that up by 
sprinkling in some emscripten_async_run_in_main_runtime_thread etc., and 
that appeared to mostly work well enough.

Now, with recent Qt 6, things have apparently changed rather 
drastically.  There is no longer a single #qtcanvas DOM element, but 
each window is its own, dynamically added canvas element, and 
interaction with browser functionality that is only available on the 
browser's main thread has grown significantly.  To a point that I 
quickly gave up trying to carry my patching approach forward :)

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...?

Thoughts welcome,
Stephan