Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Dirk Gerrits dirk@dirkgerrits.com writes:
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.
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.
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#dynam...
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 ?
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.
This seems to work like a charm. Thanks a lot!
Kind regards,
Dirk Gerrits