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