[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The Scheduler

This page is part of the web mail archives of SRFI 18 from before July 7th, 2015. The new archives for SRFI 18 contain all messages, not just those from before July 7th, 2015.

> 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

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

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!