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

Re: Some comments



Marc Feeley wrote:

It is the "fully" that I don't like.  With the semantics I propose
a user can decide what is shared and what is not shared (i.e. fully
thread-local).  For example, if I want to create a thread that has
a fully thread-local binding for the parameter current-input-port
then you can simply say:
[...]

This way the user can choose what is shared and not on a
per thread basis.


Right. But there are other ways to have non thread-local storage
(simple toplevel variables for example).


That's not true. I'm probably expressing myself not clearly enough.
`make-parameter' creates a parameter in a global environment (not attached)
to any thread. Thread-creation copies the parent's parameter-env,
*but* this env will be empty if the parent has not yet changed it's
parameter-env (i.e. it is equivalent to the global env).


But can the global env be mutated by the main thread?  In other words
if the main thread does (current-output-port stderr) and (parameterize
((current-output-port stderr)) ...) does it mutate the global env?  My
understanding was that it did (thus thread creation would have to copy
the global env to get a consistent "snapshot" of the dynamic
environment).  If the global env is immutable, then parameter-env
could be as big (or bigger depending on your implementation) as the
global env.  So scalability is an issue.

The global env is never mutated by any thread besides that the values
of parameters introduced freshly are put into it (the default or
initial value).
Scalability is definitely an issue, but I don't think that it is too expensive to prevent
it from being adapted as the default behaviour, which I find more useful.


The "swapping semantics" hides a (potentially expensive) copying
operation from the user.  I prefer when expensive operations are
explicit so the user has some control over them.


Understood.


I don't believe it would confuse users... there are few users that
combine threads and parameters and mutation, and those that do can
easily understand the semantics I propose (or indeed they are perhaps
incorrectly assuming the semantics I propose which is simpler and more
in line with the R5RS semantics!).  I am not changing the semantics of
a well-established construct...

Well, I think you are. I assume many PLT users are using threads and
parameters, but I may be wrong, of course...


(BTW, there is a simple way out of this dilemma: use different
names - `make-dynamic' and `let-dynamic' come to mind, for example...)


This is why I added "make-mutable-parameter".  Once again:
make-parameter is compatible with existing systems that support
parameters, even those supporting threads.

By heavily restricting the usefulness of `make-parameter'.


Alternatively, someone (perhaps you?) could propose a SRFI giving a
different semantics for "make-parameter" and mutation in the presence
of threads.  I think my proposal is the "right" way, but I don't have
a monopoly on "rightfulness"!


I already proposed what I think is the better solution (which of course
is not necessarily "righter" - yet more practical).


cheers,
felix