Roku Developer Program

Join our online forum to talk to Roku developers and fellow channel creators. Ask questions, share tips with the community, and find helpful resources.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
EnTerr
Roku Guru

How can a Task "know" itself?

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?

PS. In other words, where is my `m.task` ?
0 Kudos
6 REPLIES 6
Veeta
Visitor

Re: How can a Task "know" itself?

0 Kudos
EnTerr
Roku Guru

Re: How can a Task "know" itself?

"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?
0 Kudos
Veeta
Visitor

Re: How can a Task "know" itself?

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.
0 Kudos
EnTerr
Roku Guru

Re: How can a Task "know" itself?

"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)
0 Kudos
Veeta
Visitor

Re: How can a Task "know" itself?

m.top isn't the Scene, it's the task component itself.  So fields on the task node are m.top.<field> and the unique id of the task component is m.top.id.  

This is what you're talking about, right?

<component name = "TestScene" extends = "Scene" >

  <script type = "text/brightscript" >
  <![CDATA[
    Function init()
      task1 = m.top.findNode("Task1")
      task1.control = "RUN"

      task2 = m.top.findNode("Task2")
      task2.control = "RUN"
    End Function
  ]]>
  </script>

  <children>
    <TestTask
      id="Task1"/>

    <TestTask
      id="Task2"/>
  </children>
</component>
0 Kudos
EnTerr
Roku Guru

Re: How can a Task "know" itself?

"Veeta" wrote:
m.top isn't the Scene, it's the task component itself.  So fields on the task node are m.top.<field> and the unique id of the task component is m.top.id.

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()?
0 Kudos