> So the swapping compensates for the effect of side effects, and gets a
> notion similar to "call/cc captures the contents of the storage
> associated with the parameters." Except it seems to break down in the
> presence of threads, as Kent explained here:
>
> http://lists.r6rs.org/pipermail/r6rs-discuss/2007-February/001536.html
There's no claim of any break down in that note, just a clarification:
call/cc effectively captures only the values of the parameters that are
parameterized in the continuation, rather than the values of all
parameters. Here's an example illustrating the difference.
Let's assume that:
parameter P1 is defined to be 0
parameter P2 is defined to be 0
thread T1 parameterizes P1 to 1 then grabs a continuation K1
thread T2 assigns P1 to 2 and P2 to 2, then invokes K1
If call/cc were to capture the current contents of *all* parameter
locations:
code run in K1 by T2 would see P1 = 1 and P2 = 0
Since, however, call/cc actually captures only the current contents of the
parameters parameterized in the continuation, only the value of P1 is
captured, and
code run in K1 by T2 actually sees P1 = 1 and P2 = 2
This allows different threads to assign different default values to its
parameters, with only those that are parameterized by a continuation
overriding those defaults. For example, I might want each thread to
redirect its diagnostic output to a different port by setting the
current-output-port parameter while letting a continuation determine the
values of other parameters via parameterize.
Kent
Received on Wed Feb 21 2007 - 11:05:04 UTC