Here is something i am puzzled about (it was like, waking up with a WTF thought) - how can a Task instance (or thread, if you will) access its own fields?
I.e. what’s the equivalent of self or this for the runner function? When task is spawned, invoker’s m is spawned but that’s not help for the run function to reach and access its “own” fields.
What am i missing? Hard to imagine there’d be design gap of such size. And no, the function in principle cannot reach the instance by walking m.top since what if there are 2 Task instances running? How can one tell itself from the other? Yes, parent can store fields in each body but what good is that if the runners cannot “reach around” and see them?
“Veeta” wrote:
The ‘m’ associative array gets cloned on thread creation.
i know that. i thought i mentioned it above - but see i said “spawned” and not “cloned”. Having copy (actually the original) of the m is no help - there should be also a pointer set in m to the Task node itself, hence m.task idea. Imagine you have 2 threads from the same task - how would the runner function know if it’s for A or B?
Ok, i see now. My understanding is that there is one global instance of the component node, even if it has spawned a number of threads. In that case m.top for all threads point to the same instance and are subject to rendezvous when accessing fields in m.top.
In order to uniquely identify them you would probably have to rely on some tricks like defining 2 different function entry points.
“Veeta” wrote:
Ok, i see now. My understanding is that there is one global instance of the component node, even if it has spawned a number of threads.
Right you are… I guess i should re-frame it - 2 Task nodes (different field content), 1 thread each, both with the same 1 runner function - how can the fn access the “owned” fields?
In that case m.top for all threads point to the same instance and are subject to rendezvous when accessing fields in m.top.
But m.top is the Scene under which both Tasks are hanging, right? If there is no m.task kin, how can the fn guess which Task it came from? I mean there should be some difference either as fn call param or in the context (m)
“Veeta” wrote:
m.top isn’t the Scene, it’s the task component itself. So fields on the task node are m.top.
Oh! Great, that will totally work. Thank you for explaining it to me!
And if there were to ever be a need to find the Scene, i imagine from m.top should just climb the tree with getParent()?