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*
On Mon, 30 Mar 2009 15:46:08 +0200, Stelian Ionescu said:
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*
Great, thanks!
bordeaux-threads-devel@common-lisp.net
-
Martin Simmons -
Stelian Ionescu