There has been little activity on this mailing list for a long time
and it is soon time to finalize the SRFI.  I have continued
implementing the SRFI and have gained some insight that require some
modifications to the SRFI.  In no particular order:

1) It is wrong to apply the priority boost when a thread is created.
   It can cause very long servicing delays in server type applications
   that spawn threads to respond to requests.  The priority boost should
   only be applied when a thread blocks.

2) There is a need for special exceptions that are detected by
   the scheduler:

      deadlock exception   raised when there are no runnable threads and
                           no threads that could possibly unblock (i.e.
                           there are no threads blocked on an I/O operation
                           and no threads waiting for a timeout)

      scheduler exception  raised when the scheduler detects an exception
                           that it cannot handle (for example
                           a low-level call, such as "select", that
                           returns an error code, or a heap overflow);
                           a scheduler exception object contains a "reason"
                           which is the exception object that can't be
                           handled by the scheduler

   But in which thread are these exceptions raised?  It can't be the
   "scheduler" thread, because no such thing exists in my model (and
   circularity problems would occur if it did exist).  Instead, it is the
   primordial thread that is made runnable and the exception is raised in
   that thread.  Notice that the primordial thread is guaranteed to exist
   because the program exits when the primordial thread terminates.  The
   primordial thread thus has a special role and it is in that thread
   that any handler for these exceptions should be placed.  If the handler
   returns normally, the primordial thread resumes what it was doing
   before (such as blocking again).

   The procedures needed are:

      (deadlock-exception? obj)         ; test for deadlock exception
      (scheduler-exception? obj)        ; test for scheduler exception
      (scheduler-exception-reason exc)  ; get the reason

3) The use of a trailing exclamation point on some procedure names is
   a bit pedantic.  For example "thread-yield!" and "thread-sleep!" do
   have side-effects on the program, but they are rather benign.
   Which of the following should drop their "!" if any?

      thread-start!
      thread-yield!
      thread-sleep!
      thread-join!
      thread-terminate!
      mutex-lock!
      mutex-unlock!
      condition-variable-signal!
      condition-variable-broadcast!

   The last 5 should probably keep the "!", but I'm not sure about
   the first 4.  Any strong opinions one way or the other?

Marc