This page is part of the web mail archives of SRFI 21 from before July 7th, 2015. The new archives for SRFI 21 contain all messages, not just those from before July 7th, 2015.
There has been little activity on this mailing list for a long time and it is soon time to finalize the SRFI. I have continued implementing the SRFI and have gained some insight that require some modifications to the SRFI. In no particular order: 1) It is wrong to apply the priority boost when a thread is created. It can cause very long servicing delays in server type applications that spawn threads to respond to requests. The priority boost should only be applied when a thread blocks. 2) There is a need for special exceptions that are detected by the scheduler: deadlock exception raised when there are no runnable threads and no threads that could possibly unblock (i.e. there are no threads blocked on an I/O operation and no threads waiting for a timeout) scheduler exception raised when the scheduler detects an exception that it cannot handle (for example a low-level call, such as "select", that returns an error code, or a heap overflow); a scheduler exception object contains a "reason" which is the exception object that can't be handled by the scheduler But in which thread are these exceptions raised? It can't be the "scheduler" thread, because no such thing exists in my model (and circularity problems would occur if it did exist). Instead, it is the primordial thread that is made runnable and the exception is raised in that thread. Notice that the primordial thread is guaranteed to exist because the program exits when the primordial thread terminates. The primordial thread thus has a special role and it is in that thread that any handler for these exceptions should be placed. If the handler returns normally, the primordial thread resumes what it was doing before (such as blocking again). The procedures needed are: (deadlock-exception? obj) ; test for deadlock exception (scheduler-exception? obj) ; test for scheduler exception (scheduler-exception-reason exc) ; get the reason 3) The use of a trailing exclamation point on some procedure names is a bit pedantic. For example "thread-yield!" and "thread-sleep!" do have side-effects on the program, but they are rather benign. Which of the following should drop their "!" if any? thread-start! thread-yield! thread-sleep! thread-join! thread-terminate! mutex-lock! mutex-unlock! condition-variable-signal! condition-variable-broadcast! The last 5 should probably keep the "!", but I'm not sure about the first 4. Any strong opinions one way or the other? Marc