[Bordeaux-threads-devel] (initial-bindings *default-special-bindings*)
Stelian Ionescu
stelian.ionescu-zeus at poste.it
Mon Mar 30 13:46:08 UTC 2009
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/bordeaux-threads-devel/attachments/20090330/100c2176/attachment.sig>
More information about the bordeaux-threads-devel
mailing list