Marc Feeley wrote:
>
> I'm not sure what you mean by reentrant in this particular case.  But
> yes it is possible that the before and after thunks (of a particular
> call to dynamic-wind) are called by different threads.  This is
> consistent with SRFI 18, specifically with the concept that dynamic
> environments are attached to continuations (i.e. when a continuation
> is created the current dynamic environment is attached to it, when the
> continuation is resumed, possibly by another thread than the one that
> created the continuation, the dynamic environment will be restored).

Ah, yes, I see it now.

>
> When writing code, you really have to think of the parameters created
> by make-parameter as read-only, and those created by
> make-mutable-parameter as read-write.  It is only to simplify the
> migration of legacy code that the parameters created by make-parameter
> are possibly mutable (with an implementation dependent semantics).

This is unfortunate, since this SRFI really moves all that "legacy"
code into non-specifiedness...
I think parameters (as used in Chez, PLT or (say) Chicken) are
(IMHO) well understood and heavily used.

>>2) `parameterize' changes the parameters by "swapping", as
>>    in the traditional implementation.
>
>
> What do you mean by "swapping"?  Do you mean that parameterize does
> not create a new cell and simply saves the content of the cell,
> changes the content of the cell for the duration of the body, and then
> restores the cell?

Right.

 > This would be unbelievably difficult to use in a
> multithreaded system, unless of course thread creation copies the
> dynamic environment of the parent (which I guess is why you want point
> 3).  Moreover, this implementation is expensive when using
> continuations to jump between different dynamic scopes (you have to
> undo a bunch of parameter mutations, and then redo a bunch of other
> mutations).

I don't think so. You could use a "copy-on-write" strategy that
copies the dynamic (parameter) environment only if a thread actually
mutates the parameter: say you have a global parameter environment,
and `make-parameter' puts the value into this. Every thread gets its
own parameter-environment (initially a copy of the parent thread's env [*]).
Then, when the parameter is referenced, you check wether the thread's
parameter-environment contains a value, and, if not, take the
global one. Mutating a parameter does the copying (if needed).
This should result in a negligible overhead for thread-creation,
and a not-too-expensive overhead in the worst case (a shallow vector
copy is used in Chicken, for example).

>
>
>>3) Make all parameters thread-local, child threads inherit
>>    the parameter-settings of their parents.
>
>
> By thread-local you mean copy the dynamic environment (including the
> cells)?  Then see my previous response to a comment by Matthew Flatt
> (to summarize: it isn't clean and it is expensive when you create a
> thread).
>

Clean? Well, that's a matter of taste. Expensive? Not necessarily
(see above).

cheers,
felix
--
[*] Note that this will be empty, unless the parent has already
created its own environment.