GNOME Bugzilla – Bug 750633
clock: Add gst_clock_abort_wait() function
Last modified: 2018-11-03 12:27:54 UTC
As mentioned in https://bugzilla.gnome.org/show_bug.cgi?id=749391#c10 , the newly introduced gst_clock_wait_for_sync() function issues a blocking wait. If this function is used inside elements for example, it is important to be able to abort the wait, for example during a PAUSED->READY state change. A gst_clock_abort_wait() function is needed that aborts the blocking wait. To that end, also extend the description of gst_clock_wait_for_sync(). It shall return FALSE if either a timeout happened or the wait was aborted.
This is a good case for a GCancellable
I don't think we want to let core depend on GIO. Also GCancellable does not help much with a GCond, the waiting would have to be changed to be around a fd of some sort.
You can hook up the "cancelled" signal. We should just bite it and add a gio dep to the core, as soon as you do any network IO we use it anyway.
> You can hook up the "cancelled" signal. We should just bite it and add a gio > dep to the core, as soon as you do any network IO we use it anyway. Not in favour of that at all, certainly not for such a fringe feature. And even the networking thing is only true if you do network I/O using our normal elements, many people/vendors don't or have their own curlhttpsrc or so (or do their network stuff outside of GStreamer and use appsrc), so I don't think that's really an argument. gio is huge in its current form, and only getting bigger. It should not be a core dependency IMO.
So if we don't use GCancellable here, we will need something similar to that. Basically something the application passes into gst_clock_wait_for_sync() and on which cancellation can happen. A bit like a clock id ;) Any ideas how to best do that without too much code?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/115.