[ruby-core:94977] [Ruby master Misc#16160] Lazy init thread local storage

Issue #16160 has been updated by nobu (Nobuyoshi Nakada).


I'm positive about this, except for the performance.
Do you have any numbers?

----------------------------------------
Misc #16160: Lazy init thread local storage
https://bugs.ruby-lang.org/issues/16160#change-81594

* Author: methodmissing (Lourens Naud=E9)
* Status: Open
* Priority: Normal
* Assignee: =

----------------------------------------
References PR https://github.com/ruby/ruby/pull/2295

### Why?

The `local_storage` member of execution context is lazy initialized and dri=
ves the `Thread#[]` and `Thread#[]=3D` APIs, which are Fiber local and not =
Thread local storage. I think the same lazy init pattern should be applied =
to the APIs below as well - reduces one `Hash` alloc per thread created tha=
t does not use thread locals.

### Lazy allocates thread local storage for the following APIs

*  `Thread#thread_variable_get` - early returns `nil` on locals Hash not in=
itialised
*  `Thread#thread_variable_set` - forces allocation of the locals Hash if n=
ot initilalised
*  `Thread#thread_variables` - early returns the empty array AND saves on H=
ash iteration if locals Hash not initialised
*  `Thread#thread_variable?` - early returns `false` on locals Hash not ini=
tialised

### Other notes

* Moved initial implementation from `internal.h` to `thread.c` local to cal=
l sites.
* Preferred `defs/id.def` for the `locals` ID (seeing this pattern used mor=
e often, but not sure if that is preferred to inline `rb_intern` yet. Eithe=
r way there's quite a few different conventions around IDs in the codebase =
at the moment and happy to help converging to a standard instead.
* Maybe a flag is overkill and `NIL_P` on `locals` ivar could also work ...

Thoughts?



-- =

https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>