On 06.12.24 16:49, Morten Sørvig wrote:
On 5 Dec 2024, at 10:49, Stephan Bergmann <sberg....@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!
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
