wasm: fix multithreaded QmlTypeLoader deadlock

Background

QmlTypeLoader loads QML types, using a worker thread (QQmlTypeLoaderThread)

On single threaded builds the worker thread is disabled, and the type loader work is done asynchronously on the main thread. Multithreaded Qt for WebAssembly does not have any special adaptations and shares the cross-platform QQmlTypeLoaderThread implementation.

Special considerations for Qt for WebAssembly

For multithreaded builds there are code paths where the main thread blocks and waits for the QQmlTypeLoaderThread. This is problematic for a couple of reasons:

• Blocking the main thread in the wasm instance prevents the web browser from doing work and from processing events, which can cause deadlocks. In particular it can block the browser from crating the web worker for the QQmlTypeLoaderThread (which the main thread is waiting on).
• Emscripten implements main thread blocking by busy-waiting, which in this case defeats the benefits of using a secondary thread. The main thread is spinning while the secondary thread runs.

So far these problems have been masked by setting PTHREAD_POOL_SIZE, which preallocates a given number of web workers at startup. This makes sure that QQmlTypeLoaderThread can run immediately.

On recent Emscripten versions (emsdk 3.1.57+) this is no longer sufficient and Qt Quick applications deadlock on startup. Qt 6.8 uses emsdk 3.1.56 for this reason.

Possible solutions

• Don't block the main thread. All QQmlTypeLoader(Thread) usage should be asynchronous. This can be done either cross-platform or for Qt for WebAssembly only.
• Don't use QQmlTypeLoaderThread on Qt for WebAssembly. Always run on the main thread, also for multithreaded builds.