Am Sa., 5. Nov. 2022 um 21:57 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@gmail.com>:
>
> Am Sa., 5. Nov. 2022 um 21:39 Uhr schrieb Shiro Kawai <xxxxxx@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