> Caveat lector:
>
> I've just realized that SRFI-18 uses Unix style priorities where lower
> values get more CPU resource. I've (out of habit) used the opposite
> language, where higher priorities get more CPU resource.

The latest revision of SRFI-18 says:

  Each thread has a "priority", which is an exact integer (where higher
  numerical values mean higher priority) ...

is this not clear?

> Which was Marc's main complaint about the THREAD-PRIORITY>?
> primitive. But the fundamental problem is that whenever you have a
> change in the priority levels of the tasks in a system the scheduler
> has to stop and get its head screwed back on straight.

Yes, but this is much easier to implement if the scheduler has a
builtin semantics for priority.

> Which leads me to wonder if some form like
>
> 	(without-scheduling <thunk>)
>
> which encapsulates Marc's:
>
>      (let ((eh (current-exception-handler)))
>        (with-exception-handler
>          (lambda (exc)
>            (thread-reorder-and-enable-scheduler! t)
>            (eh exc))
>          (lambda ()
>            <thunk>
>            (thread-reorder-and-enable-scheduler! t))))

This is not sufficient, because the actual exception handler you need
depends on context.  In my example I was assuming that the exception
handler exits the with-exception-handler, but this is not guaranteed
since exception handlers can return (which is a good thing in
general).

In my opinion, disabling scheduling with (without-scheduling <thunk>)
or any other mechanism is not an option because the runtime system may
depend critically on the thread system (for example I/O may be done by
a dedicated thread, or the real time clock may be updated by a thread,
or the memory allocator and garbage collector may run in separate
threads).

Fundamentally, thread-priority>? needs to be a lower-level procedure
that lives by different rules.  It should not be at the Scheme level.

> There is nothing in Marc's objections which doesn't apply in
> the C world *and* which doesn't also apply to an attempt to map
> everything onto integer priorities. The only exception is not being
> able to make a procedure call, which  seems a harsh restriction, and
> one that you wouldn't encounter in a C based solution.

I'm not sure how much interesting work you'll be able to do without
procedure call!

Marc