[gst-devel] Decoupled elements and schedulers

Martin Soto soto at informatik.uni-kl.de
Wed Mar 31 01:35:07 CEST 2004


On Tue, 2004-03-30 at 22:21, Benjamin Otte wrote:
> > Question: isn't that the purpose of those funny lock and unlock
> > scheduler operations? I saw you implemented them with something like
...
> I never found out what those functions are supposed to mean. They predate
> me and nobody uses them anymore anyway. Though you'll need a different
> prototype if you want to correctly support decoupled elements - they don't
> block elements but pads. So you'd have to change the prototype which I
> would just do, but we're having quite some ABI stability ninjas here ;)

I think we should just deprecate them. And regarding locking, I'd rather
do it as a special case of a more general wait-for-event mechanism.

> Btw and totally off topic, I'm thinking about getting rid of
> gst_bin_iterate in favour of providing schedulers with a GMainLoop in 0.9.

This is not that off topic. It makes a lot of sense to me. GMainLoops
have event support and can be very nicely integrated with the workings
of other GLib applications. Go for it! :-)

> It might be a good idea for decoupled elements to run the
> scheduler->state_transition function for every scheduler that owns one of
> the attached pads. Though that might lead to threading weirdness. Haven't
> thought about that, but if it works it's ok with me to add that.

Either that or you have an additional scheduler entry point that informs
the scheduler of state changes in decoupled pads. This would be more
consistent with your view of pads in decoupled elements as having a life
of their own, so to speak.

Regarding threads, some issues may indeed arise, since you have to live
with the fact that this method may be called from a different thread as
that running the scheduler. That means schedulers have to protect their
data structures with a lock or something. I'm doing such a thing rigth
now: when a queue element goes to the PLAYING state, cothreads must be
activated in both schedulers, which means the waiting queues for them
both must be touched.

> Feel free to add that if you're sure the scheduler->pad_unlink function
> is not run twice for the same link.

I'll look into it in the following days.

M. S.
-- 
Martin Soto <soto at informatik.uni-kl.de>
Universität Kaiserslautern





More information about the gstreamer-devel mailing list