[vpacher]

Refs obs-rust/obs-studio#2391

What and why

From the review of #10: obs_browser_initialize() hands BrowserInit() to the Qt main thread with a blocking queued call when it is called from another thread (macOS). Once Qt's main loop has finished, nothing runs that call, so a first browser source created off the main thread while OBS quits would hang it on quit.

QCoreApplication::closingDown() alone does not cover it: it is only true while the application object is destroyed, not between the end of exec() and that. So:

• The hand-over moves into RunOnQtMainThread() (browser-qt-main-thread.hpp, no CEF).
• WatchQtMainLoop(), called from obs_module_load() on the main thread, sets a flag on QCoreApplication::aboutToQuit.
• RunOnQtMainThread() does not hand over when that flag or closingDown() is set. It queues the call without blocking and waits for it in 50 ms steps; if the loop stops before the call has started, it cancels it (a queued call that runs later does nothing) and returns false. obs_browser_initialize() then leaves CEF uninitialized, as for a failed initialization.

On the main thread and without a Qt application it still calls BrowserInit() directly. Linux and Windows (their own CEF thread) are unchanged.

RED → GREEN

tests/qt_main_thread.py compiles tests/qt-main-thread.cpp against Qt Core only (no CEF, no display; --qt-lib-dir on macOS, pkg-config Qt6Core on Linux):

• RED 643f00f (the hand-over moved unchanged into the helper): while the loop runs, a worker thread's call runs on the main thread (passes); after the loop has finished, the call is still waiting after 2 s (fails).
• GREEN c01896a: both pass, 20 of 20 runs.
• tests/first_source_off_main_thread.py on macOS 26.7.1 with this branch: websocket-first and collection both render.

AI note: Claude Code (Claude Opus 5.5) wrote the change, the tests and this text under the submitter's direction, and ran the tests above on the submitter's machine.

[zackees]

Coordinator review: approved, and thanks for picking up the note from #10. You're right that closingDown() alone isn't enough: it's false between the end of exec() and the application's destruction, so aboutToQuit is the right signal.

• The handshake is sound. State changes all happen under handover->mutex: the caller cancels only while the call is still Queued, and the main-thread lambda checks for Cancelled before it runs. So func runs at most once, and the caller never returns while it's running. A call that runs after cancellation is a no-op.
• WatchQtMainLoop() runs at module load on the main thread, while the app exists. obs_browser_initialize() treats a refused hand-over as a failed initialization, which the callers already handle.
• The Qt Core-only test covers both cases (the loop running, and the loop finished).
  Note: the 50 ms poll doesn't change the other case from #10. If the main thread were blocked waiting on the caller, this still waits (now polling rather than deadlocked). No current path does that.