Am Sa., 5. Nov. 2022 um 21:57 Uhr schrieb Marc Nieper-Wißkirchen <marc.nie...@gmail.com>: > > 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.)
It's already too late here: this particular optimization is part of the sample implementation. But there are other areas where it can be improved. > Thank you very much for your feedback! > > Marc
