[slime-devel] Re: *read-default-float-format* with C-c C-k, , load-system, etc.

[Dirk Gerrits]

Helmut Eller <e9626484 at stud3.tuwien.ac.at> writes:

> Dirk Gerrits <dirk at 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