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