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.
It's nice to see the flurry of exchanges today! Let me summarize the main problems I see with the existence of a settable thread-priority>? procedure. 1) Scheduling order depends on the definition of thread-priority>? which means libraries (and any code not written by the one setting thread-priority>?) can't depend on a particular semantics for threads (in essence, threads can't be used in such code). In particular this means that the runtime system can't use threads internally (to implement I/O, real-time clock, event listener, etc). 2) The meaning of (current-thread), (current-exception-handler), and the dynamic environment in general during the execution of thread-priority>? is undefined. 3) The thread-priority>? procedure must be written with several restrictions to prevent the scheduler from being called. These restrictions are implementation dependent. For example, for the Gambit-C system the restrictions are: - no preemption timer interrupt must occur (because this might cause the scheduler to access an inconsistent queue of runnable threads) - no exception can be raised (because the exception handler is undefined) - no memory allocation can occur (because it could call the GC, which might try to display a GC report, which will try to lock an I/O buffer mutex, which might cause the current thread to block; and also because a heap overflow exception might be raised; and also because a user defined finalization procedure might be run which does "wild" things like terminate a thread), note that calling + and < and many other variable arity primitives may cause memory to be allocated for the rest parameter The restrictions may be completely different for other systems. If we use a system that is lower-level some of these restrictions may disappear. For example, if we just assume a system with the power of C, the first restriction can be solved by masking the timer signal, the second restriction does not apply because C does not have exceptions, and the third restriction does not apply because C does not have a GC. thread-priority>? is easy to write in C because you have control over every little detail of the execution. thread-priority>? is impossible to write in standard Scheme because there are unknown implicit operations that occur that the user can't control. On the other hand, the implementor of a Scheme system can implement thread-priority>? internally because he/she knows how to prevent problematic operations. Trust me, the implementation I will supply with SRFI-18 will be non-portable! So if SRFI-18 specified a settable thread-priority>? procedure, the specification would have to be so vague that it couldn't be used in portable code. In essence, the user would have to define thread-priority>? differently on each Scheme system. I think it is best to leave thread-priority>? out of SRFI-18 and let each Scheme system that can and wants to support a settable thread-priority>? to provide it as an extension to SRFI-18 and document the specific restrictions. Personally, even though it is possible to support a settable thread-priority>? in Gambit-C (with the above restrictions), I will not provide such support because the documentation would involve and expose too much of the inner workings of the system (such as which primitives allocate memory under what conditions and which don't) and it is likely that too much user code would break in subtle ways from one release of the compiler to the next. I guess what I'm saying is that I don't want Scheme to acquire the bad qualities of low-level programming languages. Marc