[gst-devel] Decoupled elements and schedulers

[Benjamin Otte]

On Tue, 30 Mar 2004, Martin Soto wrote:

> I see two ways out of this. Either you forbid an element with a loop to
> also have chains and gets, or, at least, you make clear that the chains
> and gets won't be run if there's a loop. Or, you provide some mechanism
> of mutual exclusion between cothreads, like semaphores or whatever.
> Implementing semaphores in the fair scheduler would be trivial, but
> other schedulers may have trouble, plus we would have to define an API
> for the whole thing.
>
You're correct in that an element should be either loopbased or
chain/get-based. It doesn't make sense to allow both at once unless I'm
missing something.

> Question: isn't that the purpose of those funny lock and unlock
> scheduler operations? I saw you implemented them with something like
>
> g_warning ("What's this?");
>
> and I did something similar :-)
>
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'll come to R2 and R3 below. R9 is a future extension that should allow
> > elements to transfer control to the scheduler instead of interrupting
> > control flow. The best example for this is the queue. Instead of calling
> > gst_cond_wait when the queue is full and waiting for the other pad to do a
> > g_cond_signal, I intend the queue to do a gst_scheduler_block. The other
> > side of the queue would then of course do a gst_scheduler_unblock which
> > would allow rescheduling the element.
>
> This sounds useful. Question is, if you're going to do that anyway,
> shouldn't we have a more general mechanism anyway? One thing I have
> thought of is a general event mechanism. Elements could use that for
> things like asynchronously waiting for data to be available from a file
> descriptor. I wonder if GLib's main loop can help us in that regard.
>
That sounds like a pretty nifty idea. something like
gst_element_wait_for (element, type, ...) could work here. Though that's
pretty much the same as adding a function prototype for every type...

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.

> Your description is absolutely right. One point remains, though: how do
> you know it is time to schedule the pads of a decoupled element? Some
> schedulers may need to be reported when the decoupled element changes
> its state, in order to prepare for scheduling. Mine, for example, does.
> I have a queue of cothreads waiting for processor time, and I only know
> I have to put certain threads in the queue because I know the element
> changed its state.
>
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.

> Yes, I guess that'd work for me. Would be a good temporary solution at
> least.
>
Feel free to add that if you're sure the scheduler->pad_unlink function
is not run twice for the same link.

Benjamin