Quoting Pierre R. Mai ([EMAIL PROTECTED]): > > - Start the idle loop with mp::startup-idle-and-top-level-loops > This also solves the problem of *initial-process* causing delays of a > second before e.g. newly created processes get a chance to run:
Ignoring the possibility of better solutions for a moment: Is there a good reason *IDLE-PROCESS* is not set to *INITIAL-PROCESS* by default? If I understand correctly, users who do not use threads would not get hurt by that setting and those who need them will always prefer it. BTW, did the following patch get dropped? If so, is there a chance it will get into upstream CMUCL? -------- The Lisp reader has READ-BUFFER and other global variables which break thread-safety. (Note that stream functions don't lock anyway, so you don't want multiple processes calling REAM-CHAR (or similar) for the same stream. However, the bug in the reader means that calling READ on entirely unrelated streams breaks!) This patch fixes the problem by binding the variables at process creation time: --- cmucl-3.0.12/src/code/multi-proc.lisp Wed Feb 20 22:14:35 2002 +++ cmucl-3.0.12-mpread/src/code/multi-proc.lisp Thu Jun 6 06:34:14 2002 @@ -399,11 +399,22 @@ ;;; but *interrupts-enabled* and *gc-inhibit* must be the last two. ;;; (defun initial-binding-stack () - (vector - (find-package "COMMON-LISP-USER") '*package* - ;; Other bindings may be added here. - nil 'unix::*interrupts-enabled* - t 'lisp::*gc-inhibit*)) + (let ((cl::read-buffer "") + (cl::read-buffer-length 0) + (cl::inch-ptr 0) + (cl::out-ptr 0)) + (cl::init-read-buffer) + (vector + (find-package "COMMON-LISP-USER") '*package* + ;; Make the reader thread-safe + cl::read-buffer 'cl::read-buffer + cl::read-buffer-length 'cl::read-buffer-length + cl::inch-ptr 'cl::inch-ptr + cl::ouch-ptr 'cl::ouch-ptr + '() 'cl::read-from-string-spares + ;; Other bindings may be added here. + nil 'unix::*interrupts-enabled* + t 'lisp::*gc-inhibit*))) ;;; Make-Stack-Group -- Interface ;;;
