Stephan Bergmann
85933f0473
Otherwise, running the embindtest code in a LOKit-based scenario (analogously to how it is run under certain circumstances via --post-js $(SRCDIR)/unotest/source/embindtest/embindtest.js in desktop/Executable_soffice_bin.mk) would cause a deadlock when TestThread::execute (in unotest/source/embindtest/embindtest.cxx) calls SolarMutexGuard g; on that additional thread, but the main thread never released the SolarMutex because of that acquire in lo_runLoop. The code in lo_runLoop had originally been added withb693fb5cf1"We apparently need to drop the Solar Mutex when exiting lo_runLoop() on iOS" (curiously using explicit calls to acquire and release, instead of using an additional SolarMutexGuard; the difference being that a SolarMutexGuard would automatically be released upon an exception, which skips the explicit call to release), originally only for iOS, then extended to Android with0abdf307ea"android: Unregistering in runLoop() is important even on Android", then extended to Emscripten with1e421b30e2"Attempt to add ifdefs for WASM (Emscripten) for LOKit-based code" for no apparent reason. I have no idea how the Android and iOS scenarios are meant to cope with soffice_main being called with SolarMutex being acquired twice, so that no other threads could ever acquire it (except thanks to temporary uses of SolarMutexReleaser, which might explain things). However, what happens in the Emscripten scenario is that executing soffice_main leads to a call to emscripten_set_main_loop_arg in SvpSalInstance::DoExecute (vcl/headless/svpinst.cxx), which quits by throwing an exception all the way to the JS event loop, so that in lo_runLoop the inner SolarMutexGuard automatically gets released, while the outer explicit call to release got skipped, leaving the SolarMutex locked forever on the main thread. As there is no apparent reason why the Emscripten scenario should have this double locking here (and the call to vcl::lok::unregisterPollCallbacks at the bottom of lo_runLoop would never be executed in the Emscripten scenario, anyway, thanks to the exception being thrown from emscripten_set_main_loop_arg), and1e421b30e2"Attempt to add ifdefs for WASM (Emscripten) for LOKit-based code" maybe just added it in a blind copy/paste, lets just skip it. (And add a DBG_TESTNOTSOLARMUTEX to the embindtest code, to document that code's assumptions.) Change-Id: Ibae0d1d8b5f29f08d30829251ed2bb58413ea4e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188973 Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com> Tested-by: Jenkins
Tests for UNO
Contains tests for UNO