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

[Helmut Eller]

Dirk Gerrits <dirk at dirkgerrits.com> writes:

>> 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:

No; not since June.

>   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 think only the last 2 lines are created by one ,load-op.  At least
(load (compile-file ...)) produces only 2 lines.  It would also be
strange to have a thread id (23673) smaller than the id of the SBCL
REPL thread (23706).

> 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?

Only if you do it before the other threads are created, of course.  If
you do it afterwards, the value in the other threads remains
unchanged.

>> 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.

Not sure about Corman, but in Allegro the dynamic environment in new
thread is initially empty.  See
http://www.franz.com/support/documentation/7.0/doc/multiprocessing.htm#dynamic-environments-1

>> 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.

I added a new variable *default-worker-thread-bindings* instead.
The intended use is something like 

 (push (cons '*read-default-float-format* 'long-float)
       *default-worker-thread-bindings*)

Only new worker threads are affected by this variable.  To change the
variable in the REPL you have to evaluate a setq in the REPL thread.

Helmut.