[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.

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?


> 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

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

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

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