search

centricular / gstcefsrc

A simple gstreamer wrapper around Chromium Embedded Framework
86 stars 45 forks source link

Fix deadlock on macOS when running GStreamer in the main thread #86

Closed amyspark closed 3 months ago

amyspark commented 3 months ago

Hi,

This addresses the issue in https://github.com/centricular/gstcefsrc/pull/83#issuecomment-2208943286 where CEF would deadlock on launch on macOS. I traced it to an incorrect assumption in my code, that GStreamer would always run in a separate thread; in the supplied app, GStreamer is handled from the Cocoa event loop.

While this was already addressed for the CEF startup itself, it didn't account for GStreamer's code flow before CEF initialization (GstElement's start handler runs before the call to run_cef) and on shutdown (there was no check for main thread, so the deadlock would've occurred on the call to dispatch_async_f).

Let me know if this is OK; I tested it locally with gst-launch-1.0 and observed no issues.

cc @reinismu , can you check with your Nix recipe?

amyspark commented 3 months ago

I found another one, this one comes from existing code. CefPostTask does not seem to if it's running in the main thread, so it'll post the task asynchronously. Then the semaphore will wait endlessly. I've added the same checking code as in src_start and src_stop.

With that I get the app running, it seems to be waiting for an outside connection -- I take that's expected @reinismu .

sdroege commented 3 months ago

set_caps() and set_property() are calling browser APIs but those would be called from arbitrary threads. Is that OK?

amyspark commented 3 months ago

set_caps() and set_property() are calling browser APIs but those would be called from arbitrary threads. Is that OK?

Yes, that's OK. They get processed by separate threads within CEF.

sdroege commented 3 months ago

Yes, that's OK. They get processed by separate threads within CEF.

This API is very confusing :)