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 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