Is it pushed? The visible HEAD on github is 6a2319d. Actually I was composing an email regarding per-thread parameters. As I'm revising Gauche to adopt srfi-226, some concern arose from users. In most use cases, the existing code that uses parameters for thread local storage can be rewritten using thread-locals. However, there are cases that it's not trivial to migrate; for example, a parameter is defined elsewhere, and a library mutates it, assuming it's thread-safe. It is ok if the library can rewrite it using parameterize to avoid mutation, but it's not always trivial. So I plan to provide per-thread parameters at least for a while during transition.
On the other hand, per-thread parameters do seem to complicate implementation. My plan is to copy the parameterization chain when a thread is created, and normal parameters would share a box, while per-thread parameters would have separate boxes. It incurs more overhead of thread creation. I wonder if there's a better way. On Sat, Nov 5, 2022 at 9:52 AM Marc Nieper-Wißkirchen <marc.nie...@gmail.com> wrote: > I have added > > make-thread-parameter > > to SRFI 226 (see my personal repo). > > Am Mi., 8. Sept. 2021 um 10:19 Uhr schrieb Shiro Kawai < > shiro.ka...@gmail.com>: > > > > Regarding the semantics of parameter mutation. The draft says: > > > > Moreover, this specification makes a decision on the behavior of mutable > parameter objects with respect to multiple threads. If a parameter that is > inherited by a newly created thread and has not been reparameterized is > mutated by one of the threads, the mutation will also (eventually) be > observed by the other thread. This is a clear semantics because this is the > same behavior as implemented by lexical variables. > > > > Although I agree that the proposed semantics can be considered parallel > to the lexical variable semantics, I argue against it: Shared mutable > parameters are of little use. > > > > It is unreliable to use it for inter-thread communication, for the > parameter can be reparameterized without your knowledge, because of its > "dynamic scoping" nature. That means you can't locally determine the > effect of mutating a parameter (whether it's thread-local or shared), so > you have to always reparametize when you need to mutate a parameter with a > consistent behavior. > > > > Besides, there's no guarantee on atomicity of mutating parameters. It's > always better to use dedicated synchronization primitives for inter-thread > communication. > > > > On the other hand, thread-local parameter mutation comes handy. For > example, suppose you want a library that collects per-thread event logging. > > > > (define log-sink (make-parameter #f)) ;; (<thread> . <sink>) > > > > (define (get-sink) > > (let ((p (log-sink))) > > (if (and p (eq? (car p) (current-thread))) > > (cdr p) > > (let ((sink (make-sink))) > > (log-sink (cons (current-thread) sink)) > > sink)))) > > > > (deifne (log-push! item) > > (write-log-to-sink item (get-sink))) > > > > We want log-push! to work just by importing to the code that uses it. > We don't want to (or even can't) go to where the thread is created and > wrap the thread thunk with (parameterize ((log-sink #f)) ...). > > > > Gauche has been using this thread-local parameters, so I don't know if > there's a useful case for shared-mutable-state parameters. I'd like to > know if there are some. > > > > > > > > > > > > >
