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

Reply via email to