Roku Developer Program

Developers and content creators—a complete solution for growing an audience directly.
cancel
Showing results for 
Search instead for 
Did you mean: 
EnTerr
Level 8

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
Highlighted
Veeta
Level 7

Re: How can a Task "know" itself?

0 Kudos
EnTerr
Level 8

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
Level 7

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
Level 8

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
Level 7

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
Level 8

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