My first thought was that local variables accomplish something similar. But I guess they're perhaps too limited in how they can be accessed...
My second thought was to wonder how this interacts with the pyx dispatch system, where we do not know what thread will handle the task. My third thought was to wonder about how to clean this up, and how to debug issues related to it. So, ... now I am wondering if this should be "task local storage" rather than "thread local storage" -- in other words, perhaps these values should be discarded when the task completes? (This would still be "thread local", just shorter duration...) Thanks, -- Raul On Thu, Jun 9, 2022 at 2:32 AM Elijah Stone <elro...@elronnd.net> wrote: > > I propose that thread-local storage is a good idea. I suggest the following > design: > > - Within a locale, some variables may be designated as _thread-local_ (TLS). > Mutation of thread-local variables affects only the thread which affected the > mutation. > > - TLS designation is a function of _namespace_, not _name_. It is possible to > have a thread-local variable and a shared variable which have the same name. > > - When a task is created, it inherits its parent's thread-local variables. > > - A thread-local variable named 'x' is referred to using 'x_.'. Similarly > 'x_l__.' and 'x__l_.'. A self-effacing reference to a thread-local variable > is given by 'x_.:' etc. > > Thoughts? > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
