It's nice to see the flurry of exchanges today!  Let me summarize the
main problems I see with the existence of a settable thread-priority>?
procedure.

1) Scheduling order depends on the definition of thread-priority>?
   which means libraries (and any code not written by the one setting
   thread-priority>?) can't depend on a particular semantics for
   threads (in essence, threads can't be used in such code).  In
   particular this means that the runtime system can't use threads
   internally (to implement I/O, real-time clock, event listener,
   etc).

2) The meaning of (current-thread), (current-exception-handler), and
   the dynamic environment in general during the execution of
   thread-priority>? is undefined.

3) The thread-priority>? procedure must be written with several
   restrictions to prevent the scheduler from being called.
   These restrictions are implementation dependent.  For example,
   for the Gambit-C system the restrictions are:

    - no preemption timer interrupt must occur (because this might
      cause the scheduler to access an inconsistent queue of runnable
      threads)

    - no exception can be raised (because the exception handler is
      undefined)

    - no memory allocation can occur (because it could call the GC,
      which might try to display a GC report, which will try to lock
      an I/O buffer mutex, which might cause the current thread to
      block; and also because a heap overflow exception might be
      raised; and also because a user defined finalization procedure
      might be run which does "wild" things like terminate a thread),
      note that calling + and < and many other variable arity
      primitives may cause memory to be allocated for the rest
      parameter

   The restrictions may be completely different for other systems.  If
   we use a system that is lower-level some of these restrictions may
   disappear.  For example, if we just assume a system with the power
   of C, the first restriction can be solved by masking the timer
   signal, the second restriction does not apply because C does not
   have exceptions, and the third restriction does not apply because C
   does not have a GC.  thread-priority>? is easy to write in C
   because you have control over every little detail of the execution.
   thread-priority>? is impossible to write in standard Scheme because
   there are unknown implicit operations that occur that the user
   can't control.  On the other hand, the implementor of a Scheme
   system can implement thread-priority>? internally because he/she
   knows how to prevent problematic operations.  Trust me, the
   implementation I will supply with SRFI-18 will be non-portable!

So if SRFI-18 specified a settable thread-priority>? procedure, the
specification would have to be so vague that it couldn't be used in
portable code.  In essence, the user would have to define
thread-priority>?  differently on each Scheme system.  I think it is
best to leave thread-priority>? out of SRFI-18 and let each Scheme
system that can and wants to support a settable thread-priority>? to
provide it as an extension to SRFI-18 and document the specific
restrictions.

Personally, even though it is possible to support a settable
thread-priority>? in Gambit-C (with the above restrictions), I will
not provide such support because the documentation would involve and
expose too much of the inner workings of the system (such as which
primitives allocate memory under what conditions and which don't) and
it is likely that too much user code would break in subtle ways from
one release of the compiler to the next.  I guess what I'm saying is
that I don't want Scheme to acquire the bad qualities of low-level
programming languages.

Marc