This page is part of the web mail archives of SRFI 39 from before July 7th, 2015. The new archives for SRFI 39 contain all messages, not just those from before July 7th, 2015.
At Mon, 30 Dec 2002 10:24:38 -0500, Marc Feeley wrote: > This works if at thread creation the dynamic environment is flagged as > "to be copied on mutation" and both parent and child continue with a > reference to this environment. But I would say that this lazy copying > can be quite expensive... in fact it can be up to twice as expensive > as taking a fresh (eager) copy of the parent's dynamic environment for > the child thread, because both parent and child may end up copying the > whole dynamic environment. Well, the "copy on write" indicator is a counter. If the counter is zero, everyone else has already made a copy, and the current one is mutable. > Having to copy the whole environment or > some large fraction of it is likely in the swapping semantics because > it handles "parameterize" by mutating parameter objects. So my point > that the "swapping" semantics makes thread-creation expensive remains > (the cost may not be paid immediately, but it will slow down the > execution of the program as a whole). Some algorithms remain slow, perhaps including MzScheme's current algorithm. It's not obvious to me that no efficient algorithm exists. > Aside from this I'm curious about the representation of the dynamic > environment in PLT and Chicken. I don't think it exists. A parameter corresponds to a thread-local variable. `parameterize' expands to a use of `dynamic-wind': the pre-thunk installs a value into a parameter while saving the old value, and the post-thunk swaps the old value back in. Since ICFP, I've understood that this isn't the right model --- mainly because it's difficult to reason about moving a continuation from one thread to another. I generally like the model you've proposed, and I expect to add one extra function: something like `call-in-new-parameterization' that evaluates a thunk with fresh bindings for all parameters (keeping the current value for each parameter). That's the function that you claim is hopelessly expensive. :) Probably, this function will be used implicitly im many places, such as module invocation, and I think it will help avoid many "security" holes. Of course, the `thread' primitive will use `call-in-new-parameterization' to evaluate its thunk, thus preserving the old MzScheme behavior. If it ever seems useful, we could add a `make-mutable-parameter' that creates parameters to be skipped by `call-in-new-parameterization'. But MzScheme's built-in parameters can't change to "mutable" parameters whose bindings are shared by threads. Our libraries would fall apart. Matthew