parameter mutation and per-thread storage
Shiro Kawai
(08 Sep 2021 08:19 UTC)
|
Re: parameter mutation and per-thread storage
Marc Nieper-Wißkirchen
(08 Sep 2021 09:24 UTC)
|
Re: parameter mutation and per-thread storage
Shiro Kawai
(09 Sep 2021 04:14 UTC)
|
Re: parameter mutation and per-thread storage
Marc Nieper-Wißkirchen
(13 Sep 2021 08:32 UTC)
|
Re: parameter mutation and per-thread storage
Shiro Kawai
(17 Sep 2021 00:07 UTC)
|
Re: parameter mutation and per-thread storage
Marc Nieper-Wißkirchen
(21 Sep 2021 15:55 UTC)
|
Re: parameter mutation and per-thread storage
Shiro Kawai
(22 Sep 2021 20:24 UTC)
|
Re: parameter mutation and per-thread storage
John Cowan
(10 Sep 2021 02:33 UTC)
|
Re: parameter mutation and per-thread storage
Marc Nieper-Wißkirchen
(13 Sep 2021 07:47 UTC)
|
Re: parameter mutation and per-thread storage Marc Nieper-Wißkirchen (05 Nov 2022 19:52 UTC)
|
Re: parameter mutation and per-thread storage
Shiro Kawai
(05 Nov 2022 20:39 UTC)
|
Re: parameter mutation and per-thread storage
Marc Nieper-Wißkirchen
(05 Nov 2022 20:57 UTC)
|
Re: parameter mutation and per-thread storage
Marc Nieper-Wißkirchen
(05 Nov 2022 21:00 UTC)
|
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 <xxxxxx@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. > > > > > >