>    By the way, I would like to see how you would structure a
>    changeable scheduler that supports all the features proposed in
>    SRFI-18.
>
> > Further (and relatedly), I'm curious why priority and quantum are
> > defined as the only thread-related data that affect the
> scheduling. If
> > the scheduling algorithm were separate, there might be other data it
> > would want to consider (e.g., deadlines).
>
> This is an open-ended issue.  I'm proposing a basic (but not minimal)
> thread system with features similar to those found in mainstream
> thread systems.  In fact the thread system I propose is more powerful
> than most mainstream thread systems (for example few thread systems
> support per thread quantums and absolute timeouts).  If there is a
> need for other "non-mainstream" features, such as deadlines, then a
> new SRFI can be proposed.  My hope is that it will be a pure extension
> of SRFI-18 (that is why it is important to have a scheduling semantics
> that is not too restrictive).
>
> Marc
>
>

Maybe I'm just suggesting that 'priority' be made more generic, and that
a partial order of threads be specified. Perhaps specifically, that a
THREAD-PRIORITY>? procedure be defined (which could be redefined by 'the
user'). Of course, this would mean removing the restriction that
thread-priority be an "exact integer (where higher numerical values mean
higher priority)."

It may be the case the quantum should be factored into this, as well as
the amount of time a thread has become runnable. I suspect not.

If the THREAD-PRIORITY>? approach were adopted, then the 'fairness
constraints' section remains the same, the 'priority aging' issue goes
away (user x, want to implement priority aging? Just change
THREAD-PRIORITY>? to reflect this), I could implement deadlines, etc.

What do you think? Does this mess up the semantics too much? Make things
too inefficient?