[gst-devel] GstBin and scheduling

[Erik Walthinsen]

Well, gstbin.c has broken a thousand lines.  Only gstpad.c comes close at
881 lines.  This means that there is considerable complexity hidden in
there somewhere...

The scheduling system is nearing complete for the purposes of task 22588,
but there is probably more work to do in the long run.  One of the biggest
tasks will be refactoring it so it actually makes sense.  It's slowly
being hacked into oblivion right now, and only a serious working over will
really make it any clearer.

What I've done just now is to modify the way out-of-bin elements are
scheduled.  Previously they were simply assigned a cothread context and
away you went.  This doesn't work all that well when you have cothreads on
both sides of a connection.  You end up with both Bins setting the
cothread pointer, and one or the other will lose out and scheduling for
the other will grind to a screeching halt when it tries to switch to a
cothread in a different thread.  Whoops.

THe solution as of now is to detect these cases (currently just the source
case, but I just found out the hard way that the sink case is needed as
well) and construct a special scheduling structure.  This structure is
then filled in with the element, a cothread context, and a list of pads
that are specific to that context, which is tied to the bin that owns that
struct.

When it's time to switch into the first element, the entry pointer is
checked to see if it's an element.  If it is, normal things happen.  If
not, slightly different code causes a switch into the cothread for that
sched struct.

This isn't very efficient at plan creation time, since it has to go
through lists multiple times, and do a lot of decision-making.  As I
started to write this message, though, a thought occured to me:

We don't really have to use cothreads for non-loopfunc-based sources and
connections.  If they're not loopfunc-based, we can simply call their
pullfunc or chainfuncs directly, as if we were in chaining (non-cothread)
mode.  This hybrid approach may be taken eventually anyway as the Bin gets
more and more intelligent.  It makes sense to start doing this now, since
cothreading this stuff is a pain.

The codebase I've got now is rather broken, I'll see if I can fix it and
get it into a semi-usable state for source pads only (i.e. if you try to
cothread the elements connected to the sink of the connection [i.e.
disksrc], it'll fail utterly).  Once that's in CVS, I'll then go and
replace it with something that uses the hybrid scheduling approach.  It
may take a while to get it right, but it'll be worth it.

I have to get up early (8:45) tomorrow and won't get home until about
3:30, but after that I'll try to get everything coded up and finally close
23098 and 22588.

         Erik Walthinsen <omega at cse.ogi.edu> - Staff Programmer @ OGI
        Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/
   Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/
        __
       /  \             SEUL: Simple End-User Linux - http://www.seul.org/
      |    | M E G A           Helping Linux become THE choice
      _\  /_                          for the home or office user