Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Dirk Gerrits dirk@dirkgerrits.com writes:
Something like this?
#+:sb-thread (when (find-package :swank-loader) (setf (sb-thread::symbol-value-in-thread *read-default-float-format* (the-right-thread)) 'long-float))
Sounds reasonable, but I haven't found the right thread yet. Any SLIME developers who can help?
The thread tree looks like this:
inferior-lisp (== SBCL REPL) _ socket server [usually dead] _ reader thread _ repl thread _ control thread _ worker thread1 _ worker thread2 ...
REPL command are executed by the repl thread. For the other request, a new worker thread is created by the control thread. So, the-right-thread(s) are probably the control thread and the repl thread.
This seems strange. Has any of this changed recently? It doesn't seem to explain the behaviour I reported earlier:
In my package.lisp file, I've got the following:
(eval-when (:compile-toplevel :load-toplevel :execute) (with-open-file (stream "thread-id.txt" :direction :output :if-exists :append) (print (sb-thread:current-thread-id) stream))
;; Use long-floats instead of single-floats by default. (setq *read-default-float-format* 'long-float))
When I do a ,load-system of my ASDF system from the REPL, the processing of this file generated thread-ids:
23673 23710 23710
The REPL has thread-id 23710 as well. So I guess COMPILE-OP is done in a seperate thread but LOAD-OP is done in the REPL thread? Using the *inferior-lisp* buffer's REPL reports 23706, by the way.
This says inferior-lisp /= SBCL REPL, and the SETQ was apparently executed in the REPL thread yet the binding wasn't inherited by the worker threads.
I'll try this out again soon. If the thread tree is really as you describe, and ,load-system is done in the SCBL REPL thread, then there shouldn't be a problem at all, right?
sb-thread::symbol-value-in-thread doesn't appear to be setf-able here,
Indeed, Christophe asked whether it would help me if he added it to SBCL.
but
(sb-thread:interrupt-thread (swank::connection.control-thread swank::*emacs-connection*) (lambda () (setq *read-default-float-format* 'long-float)))
seems to work.
Okay, I'll try this.
The issue came up before but I still don't know what the proper fix is. SBCL is the only Lisp with the inherit-dynamic-variables-in-new-threads semantics.
I thought AllegroCL 7 and Corman Common Lisp (and possibly others) also behaved in this way? In any case, it seems to me that this is the reasonable thing to do with special variable bindings in a multithreaded setting.
Implementing non-inheriting seems to be difficult in SBCL and implementing inheriting is difficult in the other Lisps. We could probably offer something like swank:setq-default to set initial values in the worker threads. Other ideas?
I reckon the problem is a lot deeper than SBCL + SLIME, but SWANK:SETQ-DEFAULT sounds like a good workaround.
Kind regards,
Dirk Gerrits