[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some comments

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