[gst-devel] Scheduler unification / cothreads
wingo at pobox.com
Tue Apr 23 08:43:08 CEST 2002
On Tue, 23 Apr 2002, Benjamin Otte wrote:
> I was thinking about unifying the API of our two cothreads packages, so
> that we only need one source file and can compile both schedulers with a
> little Makefile magic.
> I don't think there is a reason why we have to seperated them because both
> cothread packages are functionally equivalent.
I have a bad gut feeling about this, but...
> And I don't like having fixes only applied to one scheduler either :)
This is key. I'm definitely with you on this one. However, I would be
more in favor of including different headers that would define macros
differently depending on whether -DSCHED_STANDARD or -DSCHED_BASIC are
passed on the gcc compile line.
> After I looked at it, I found out that the naming of functions / structs
> is slightly different.
Well duh ;)
> I've listed those, that are currently used below (Left side is the old
> cothreads, right side the
> new one):
> - cothread_state vs cothread
> - cothread_context vs not used
This is a key difference. The old cothreads package requires that
cothreads live inside some sort of context, whereas the new one keeps
track of all that data for you. There are many limitations, IMO, with
the cothread_context idea. This is not just an api difference.
> - cothread_context_init vs cothreads_init (prototype is different)
cothread_context_init() must be called for every thread and every
pipeline. Although more that one pipeline is not allowed within the same
thread under the old package (they are with the new package).
cothreads_init() is only called once.
> - cothread_context_free vs not used
because in the new package there are no contexts.
> - cothread_switch (different prototype)
> - cothread_create (arguments are given in other order)
> - cothread_setfunc vs cothread_reset (different prototype)
> - cothread_free vs cothread_destroy
> - cothread_lock vs not used
> - cothread_unlock vs not used
> - cothread_current_main vs saving main cothread in scheduler struct
> - cothread_set_private (this functions is used in the scheduler but isn't
> So the question is:
> What is the preferred way of our thread package maintainers to achieve
> this unification?
I think it would look something like this:
and have compatibility macros defining a superset of both cothread
now my honest opinion is that the old cothreads package has too many
fundamental limitations to be worth it, and that folks should
concentrate on making the new one better. but that's just MNSHO.
More information about the gstreamer-devel