Ulrich Hobelmann  <u.hobelmann@web.de> wrote:
+---------------
| Ron Garret wrote:
| > That fails if you have multiple threads. This was discussed to death 
| > last January.  Google for the thread called "Smug Scheme weenies."
| 
| If you have multiple threads referencing the same special variable, yes. 
|   I'd consider that very bad style though and make all special variables 
| per-thread by default...
+---------------

That doesn't work, either! How could you possibly share global data
if *all* special variables were per-thread?!? Remember, Common Lisp
has nothing *but* special variables as globals.

No, what most Common Lisp implementations which provide threads
actually do is "the right thing":

1. If a thread has not LET-bound (or LAMBDA-bound) a global/special
   variable, it sees the same binding as other threads which have not
   bound it. A SETF by any such thread is seen by all such threads.

2. If a thread LET-binds (or LAMBDA-binds) a special variable, then
   that binding is thread-local for the dynamic duration of that
   binding. A SETF or rebinding of that special variable while so
   bound will be seen only by that thread. [Other special variables
   which have not been LET/LAMBDA-bound by that thread will behave
   as in #1.]

   Conversely, such a thread will not see any SETFs to a variable
   it has bound by non-binding threads (as in #1) until it exits the
   LET/LAMBDA- binding contour, at which point it will see whatever
   the current "global" value happens to be.

Said more succinctly: If you want a special variable to be thread-
local, bind it. If you want it to be global, SETF it.

To my knowledge, ACL, Corman Lisp, CMUCL, & SBCL all behave this way,
and probably others as well. [LW?]


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607