I inserted pause b/c Chez doesn't seem to allow a continuation to be invoked when its capturing thread has already terminated.
Anyway, my thought process is this: - The call/cc captures the current parameterization, which is p == 2. - Thus, when that continuation is invoked in a different thread, the parameterization p == 2 is restored, and prints ">>> 2". So, SRFI-226 disagrees with Chez and agrees with Gauche, correct? On Wed, Sep 13, 2023 at 6:30 AM Marc Nieper-Wißkirchen < marc.nie...@gmail.com> wrote: > Don't you have a race condition in your example because you don't wait for > the first thread to terminate? > > In any case, the current set of parameters (the "current parameterization" > in the SRFI 226 language) is part of the current continuation. So when you > replace the current continuation, you replace the current parameterization > as well. > > Does this help? > > Am Mi., 13. Sept. 2023 um 18:17 Uhr schrieb Shiro Kawai < > shiro.ka...@gmail.com>: > >> I brought it up because the SRFI-226 thread parameter behaves differently >> from Gauche legacy parameter which also uses thread-local storage (The >> difference actually comes from the fact that parameterize is realized by >> dynamic-wind in legacy parameter.) >> >> But maybe I don't fully understand the implication of interaction of >> parameters. So let me back up one step. >> >> If I run the following code in Chez REPL, I get ">>>2" from the first >> thread, and ">>>1" from the second thread. If I run the equivalent code in >> Gauche, the second thread prints ">>>2" as well, for the call/cc captures >> the dynamic environment and restores it in the second thead. Does >> SRFI-226 agrees with Chez? >> >> ==== >> (define cc #f) >> (define p (make-parameter 1)) >> >> (define (pause) (sleep (make-time 'time-duration 0 10000))) >> >> (fork-thread >> (lambda () >> (parameterize ((p 2)) >> (call/cc (lambda (k) (set! cc k))) >> (format #t ">>> ~s\n" (p)) >> (pause)))) >> >> (fork-thread cc) >> ==== >> >> >> >> >> On Tue, Sep 12, 2023 at 9:38 PM Marc Nieper-Wißkirchen < >> marc.nie...@gmail.com> wrote: >> >>> Parameters can be equivalently expressed in terms of fluids (see SRFI >>> 226), which mimic variables. Thread parameters are to parameters what >>> thread-local fluids are to fluids, so one argument is symmetry. >>> >>> Often, you want to use thread-local objects in conjunction with the >>> parameter mechanism, so thread parameters come in handy. The nice thing >>> about them being defined natively is that they can then share the same form >>> to parameterize them as non-thread local parameters. >>> >>> For good "real world" examples, take a look at the documentation of the >>> Chez system. Some of its parameters are non-thread local; others are >>> thread-local. (NB: Chez's parameters are just parameter-like objects in the >>> language of SRFI 226.) >>> >>> >>> Am Mi., 13. Sept. 2023 um 08:19 Uhr schrieb Shiro Kawai < >>> shiro.ka...@gmail.com>: >>> >>>> I'm preparing for a new release of Gauche which supports part of >>>> SRFI-226. While documenting it, I noticed I couldn't recall why thread >>>> parameters were added, and what for. I remember It was added at some >>>> point, but I can't find any discussion about it. I may have just >>>> overlooked it. Can somebody (Marc?) help me recall it? >>>> >>>> I do remember we discussed whether parameter storage should be >>>> thread-specific or not, and I concurred that it should not. Thread-local >>>> storage can be realized by thread locals. Is there a case that you need >>>> parameters to be thread specific? >>>> >>>> --shiro >>>> >>>> >>>>
