[Bordeaux-threads-devel] (initial-bindings *default-special-bindings*)
I'm not sure that this is a good idea. The authors of the latest Hunchentoot seem to have missed completely that MAKE-THREAD resets a whole lot of special variables (esp. *print-readably* which produces lots of confusing errors in the handlers of HT 1.0). Why not inherit the values from the parent thread by default? Leslie -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/
On Wed, 25 Feb 2009 21:53:42 +0100 (CET), Leslie P Polzer said:
I'm not sure that this is a good idea.
I agree. I think the set of default bindings should be very minimal, not including any of the CL I/O variables.
The authors of the latest Hunchentoot seem to have missed completely that MAKE-THREAD resets a whole lot of special variables (esp. *print-readably* which produces lots of confusing errors in the handlers of HT 1.0).
Why not inherit the values from the parent thread by default?
I think inheriting values is worse in general, because it leads to accidental capture of values that should be specific to each thread. -- Martin Simmons LispWorks Ltd http://www.lispworks.com/
I agree. I think the set of default bindings should be very minimal, not including any of the CL I/O variables.
Moreover this should be fixed ASAP since it affects library (e.g. Hunchentoot) user applications severely.
I think inheriting values is worse in general, because it leads to accidental capture of values that should be specific to each thread.
I'm not sure we're on the same page here: I intend to have only the values inherited, not the bindings themselves. Is that the meaning you picked up? Leslie -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/
On Fri, 27 Feb 2009 09:39:54 +0100 (CET), Leslie P Polzer said:
I agree. I think the set of default bindings should be very minimal, not including any of the CL I/O variables.
Moreover this should be fixed ASAP since it affects library (e.g. Hunchentoot) user applications severely.
Sorry, I can't help there.
I think inheriting values is worse in general, because it leads to accidental capture of values that should be specific to each thread.
I'm not sure we're on the same page here: I intend to have only the values inherited, not the bindings themselves.
Is that the meaning you picked up?
Yes, I talking about the values too. I dislike inherited values becuase you don't always know when threads will be created, e.g. a library might start a background maintenance thread when you call it for the first time. Inheriting values from the dynamic environment where that happens is undesirable IMHO. Moreover, inheriting the value of any mutable object (e.g. readtable, pprint dispatch table) means sharing it between threads, which is little better than sharing the global value. -- Martin Simmons LispWorks Ltd http://www.lispworks.com/
participants (2)
-
Leslie P. Polzer -
Martin Simmons