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