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

[Helmut Eller]

Dirk Gerrits <dirk at dirkgerrits.com> writes:

> Okay, now I'm confused.  
>
> As I understood it, special variable /bindings/ are inherited by child
> threads in SBCL.  Doing a SETQ in any of those threads should affect all
> those threads unless they have created a new, local binding for that
> variable with LET.
>
> Are you saying that what I'm seeing is because SBCL threads inherit
> special variable /values/ inside new, local /bindings/?  With 47 special
> variables in the COMMON-LISP package alone, that can't be right, so I
> must have misunderstood you.

Yes, it's closer to the latter version.  "inheriting the binding" was
probably not the correct term.  Sorry for the confusion.  

If the parent thread has a dynamic binding the child will also have a
dynamic binding and the value will be inherited from the parent.  The
dynamic binding itself is private to a thread and SETQ-ing it will not
change the value in other threads.  Only the global (non-dynamic)
binding is shared.

Creating a thread is probably not very fast, but Common Lisp was not
designed with concurrency in mind.

>> 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
>
> This describes exactly what I thought SBCL's (and Corman's) semantics to
> be.  Can you explain the difference with
> http://www.sbcl.org/manual/Special-Variables.html ?

Here's an example: 

  (defvar *dvar* 10)
  
  (let ((*dvar* 20)
        (lock t))
    (sb-thread:make-thread (lambda ()
                             (print *dvar*)
                             (setq *dvar* 30)
                             (setq lock nil)))
    (loop while lock do (sleep 0.2))
    (print *dvar*))

This prints 

  20
  20

in SBCL.  The equivalent (MAKE-THREAD replaced with
PROCESS-RUN-FUNCTION) in Allegro prints:

  10
  20

Helmut.