[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The Scheduler
> 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)))
> (lambda (exc)
> (thread-reorder-and-enable-scheduler! t)
> (eh exc))
> (lambda ()
> (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