[RFC] New pad callback type: forcefully synchronous, blocking

[Sebastian Dröge]

On Fr, 2014-01-10 at 00:41 +0200, Andrey Utkin wrote:
> I know that there is such pad callback type that are executed _surely_
> in non-synchronous (not on same stack) way - e.g.
> GST_PAD_PROBE_TYPE_BLOCK, and there is such type that _may_be_
> executed synchronously (on same stack): GST_PAD_PROBE_TYPE_BLOCKING.

Only GST_PAD_PROBE_TYPE_IDLE can be called immediately.
GST_PAD_PROBE_TYPE_BLOCKING is BLOCK|IDLE.

> It would be very handy for me (and hopefully for others, too) to have
> such pad callback type that is guaranteed to execute
> synchronously,.i.e. on same stack above gst_pad_add_probe(). Also it
> should be executed in blocking mode, so we can manage the pad safely
> in the callback. Yes, let it wait until it can execute, if needed.
> Obviously the only reasonable return value for such callback type is
> GST_PAD_PROBE_REMOVE, or the fact of single execution can be declared
> specially in documentation.
> 
> Dear developers, do you think this is possible to implement in current
> gstreamer?

That's possible to implement, also outside GStreamer with the existing
API. You just need to install a probe, use condition variables and make
sure you wake up that condition variable from the callback at an
appropriate time (especially also when flushing).

> If implemented, would a patch be reviewed for inclusion?

That's like the gst_pad_set_blocking() API in 0.10, which was considered
bad practice because it can easily cause deadlocks. Maybe the pad is
blocked now, maybe later, maybe never.
GStreamer tries to provide asynchronous APIs for that (and similar
reasons) reason, and similar things like state changes or seeking are
supposed to be asynchronous if they could block too.


That's basically the same why you really shouldn't do blocking IO in any
applications and do it all asynchronous with callbacks. That might be
more effort in C, but you're asking for that by choosing C. Higher-level
languages have special language constructs to make this easier to use.


I think what you really want is some high-level API that is safe to use
but also easy to use. Something similar to insertbin, just for your use
case and maybe more generic. A synchronous, blocking function is not the
solution for that IMHO.

-- 
Sebastian Dröge, Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140110/1cd97092/attachment.pgp>