> On 10 Dec 2024, at 14:55, Stephan Bergmann <sberg....@gmail.com> wrote:
>
> [You don't often get email from sberg....@gmail.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> 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.)
Yes, -sPTHREAD_POOL_SIZE is can be awkward to use in practice. We pulled a
default number (4) out of the air for Qt.
I think I still would try to make things work from the main thread instead of
moving off the main thread. We do want Qt to work from the main thread.
>
>>> 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!
No problem!
Morten
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
