[gst-devel] Scheduler unification / cothreads

[Andy Wingo]

On Tue, 23 Apr 2002, Benjamin Otte wrote:

> Hi,
> 
> 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):
> 
> structs
> - 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.

> functions
> - 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
> necessary)
> 
> 
> 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:

#ifdef SCHED_STANDARD
#include "cothreads-standard-compat.h"
#else
#ifdef SCHED_BASIC
#include "cothreads-basic-compat.h"
#endif
#endif

and have compatibility macros defining a superset of both cothread
packages' functionality.


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.

regards,

wingo.