Ah, Gauche uses its own array of thread local cells so it's possible to copy it when a new thread is created, but if you directly implement each thread local with the underlying system's one, it may not be easy to keep track of them.
I think inheritable thread locals are less used than non-inheritable ones and we can put them off to a later srfi as the demand arises. I wonder if mentioning the possibility of such future enhancement is worth giving hints to the implementers to make design choices. On Thu, Oct 20, 2022 at 7:43 PM Marc Nieper-Wißkirchen < marc.nie...@gmail.com> wrote: > Thanks for coming up with this. I thought about this feature when I > wrote up the spec. It is also a feature of Racket's thread cells. I > left it out because I hadn't pondered how to implement this feature > efficiently and directly with the POSIX and C11 threading libraries. > > If you have a good idea about it, I am very open to including the > feature you propose. > > Am Fr., 21. Okt. 2022 um 01:38 Uhr schrieb Shiro Kawai < > shiro.ka...@gmail.com>: > > > > In the current spec, a new thread's thread local is initialized by the > obj argument given to make-thread-local. There may be cases that the child > thread wants to see the same value as the parent thread at the moment > make-thread is called. > > > > Java has InheritableThreadLocal that does it: > > > https://docs.oracle.com/javase/7/docs/api/java/lang/InheritableThreadLocal.html > > > > There seems a proposal for C++ as well: > > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2633r0.html > > >
