-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix deadlock on macOS when running GStreamer in the main thread #86
Fix deadlock on macOS when running GStreamer in the main thread #86
Conversation
9198e83
to
96c1381
Compare
I found another one, this one comes from existing code. With that I get the app running, it seems to be waiting for an outside connection -- I take that's expected @reinismu . |
|
96c1381
to
dcd105a
Compare
Yes, that's OK. They get processed by separate threads within CEF. |
This API is very confusing :) |
@@ -778,13 +789,22 @@ gst_cef_src_start(GstBaseSrc *base_src) | |||
GST_OBJECT_UNLOCK (src); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The g_cond_wait()
10 lines above would also wait forever if we end up here on macOS on the main thread or not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not after this MR. If GStreamer is managed from the main thread, this function gets called by line 762 above, by which time either CEF has initialized (skipping the wait altogether), or it has failed (and this function will not be called at all). The wait is still necessary if the app handles CEF in a different event loop from the GStreamer pipeline's, like with gst-launch-1.0
.
Hi,
This addresses the issue in #83 (comment) 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 todispatch_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?