Am Sa., 5. Nov. 2022 um 21:39 Uhr schrieb Shiro Kawai <shiro.ka...@gmail.com>: > > Is it pushed? The visible HEAD on github is 6a2319d.
I forgot to push it. Should be visible now. > > 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. The solution in the sample implementation (see hopefully pushed commit) is to use inheritable thread-local cells. For thread parameters, parameterize creates a new inheritable thread-local cell whose default is the new value. To speed up thread creation (which needs to copy values of inheritable thread locals) observe that only those inheritable thread locals have to be copied that have ever been set. So only those have to be kept in a (weak) list. This means that parameterize means no overhead for thread creation, only mutating of a thread parameter. (I haven't made this optimization in my sample implementation yet.) Thank you very much for your feedback! Marc
