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