[Webkit-unassigned] [Bug 150888] New: [GStreamer] Do not use GThreadSafeMainLoopSource to end notifications to the main thread in MediaPlayerPrivateGStreamer
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Nov 4 02:58:22 PST 2015
https://bugs.webkit.org/show_bug.cgi?id=150888
Bug ID: 150888
Summary: [GStreamer] Do not use GThreadSafeMainLoopSource to
end notifications to the main thread in
MediaPlayerPrivateGStreamer
Classification: Unclassified
Product: WebKit
Version: WebKit Local Build
Hardware: Unspecified
OS: Unspecified
Status: NEW
Keywords: Gtk
Severity: Normal
Priority: P2
Component: Platform
Assignee: webkit-unassigned at lists.webkit.org
Reporter: cgarcia at igalia.com
CC: pnormand at igalia.com, zan at falconsigh.net
Analyzing how the main loop sources were used in GST code I've noticed that in most of the cases they are used to send notifications to the main thread. The way it works in those cases is that some state is updated in whatever thread and we notify the main thread to use the new state. There's no data passed to the main thread, they are just notifications. I've also noticed that we are not doing this exactly as expected in several of those cases. GThreadSafeMainLoopSource cancels the current source when a new one is scheduled, and that was done this way because previous code in GST using GSources directly did it that way. But that's not what we want, if there's a notification pending, since the state is updated, we can just wait for it to happen instead of cancelling and scheduling a new one. I've also noticed that in most of the cases where we schedule notifications to the main thread, we can be already in the main thread, so we could avoid the schedule entirely.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151104/cf8b1c48/attachment.html>
More information about the webkit-unassigned
mailing list