On Fri, 2009-03-20 at 20:00 +0000, Martin Simmons wrote:
> Sorry, there is confusion about what "bound" means here, since LET and SETQ
> both make a symbol bound, but they behave differently with multithreading. I
> think it is worth stating what we expect to happen.
>
> Let's use the term thread-specific binding for what is establish by LET (and
> also PROGV and the new Bordeaux-threads default bindings). Each symbol also
> has a global binding which is seen by all threads that have no thread-specific
> binding. AFAIK, all implementations support this and using SETQ with a symbol
> that has a thread-specific bindings in the current thread will not affect
> other threads.
>
> I don't want the thread-specific bindings for the I/O variables of the current
> thread to be inherited by a new thread. That's the capturing problem.
>
> Moreover, I think there should be no thread-specific bindings for the I/O
> variables in the threading library, i.e. their global bindings should be
> visible and changable. If an application wants to change the value, then it
> should rebind it with LET, not assume that it can use SETQ.
>
> I hope that makes my position clearer.
Ok, I yield to your arguments :). *default-special-bindings* now
defaults to NIL and its previous value is in *standard-io-bindings*
--
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.