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

Accessing a m.top field a second time within a task seems to freeze the task

This one is driving me crazy!

I have a Task with a timer.  After the elapsed time it sets something to m.top.test and resets the timer.  But the next time I access m.top.test the thread freezes.

Example:
 <interface>
   <field id = "test" type = "assocarray" />
 </interface>
---------
          while true
               if m.timer.TotalSeconds() >= 5
                   m.timer.mark()
                   print "TEST 1"
                   print m.top.test
                   print "TEST 2"
                   m.top.test = createObject("roAssociativeArray")
                   print "TEST 3"
               end if
           end while


This loop works great once.  The console prints "Test 1" "invalid" "Test 2" "Test 3" as expected.  However the next time the timer elapses and it sets m.top.test again it just... stops.  Freezes once it tries to print m.top.test and therefore only "Test 1" prints to the console.

If instead of printing out m.top.test I print out m.top it actually prints out the task node properly, and I'll get "Test 1" "Test 2" in the console.  
TEST 1
<Component: roSGNode> =
{
    functionName: "start"
    sleepRelease: false
    syncRelease: false
    waitRelease: false
    control: "run"
    state: "run" <----- It's running?
    change: <Component: roAssociativeArray>
    focusable: false
    focusedChild: <Component: roInvalid>
    id: ""
    test: <Component: roAssociativeArray> <----- It's there
[size=85][font=Helvetica Neue, Helvetica, Arial, sans-serif]}[/font][/size]
TEST 2



But once I try to assign to m.top.test then it freezes.
Details: This task is created by the main thread, and the main thread is observing "test" using a port for the callback.  The callback is updating a roScreen.

I assume there are some specifics about Task that I'm missing?  If anybody has run into anything similar, or there's something dumb I'm missing, I'd love to hear suggestions!
0 Kudos
6 Replies
belltown
Level 7

Re: Accessing a m.top field a second time within a task seems to freeze the task

I'm not sure why it hangs. However, I'd re-write your timer loop so it waits 5 seconds, rather than executing at full-speed checking on each iteration to see if the timer has elapsed:

timerPort = CreateObject("roMessagePort")
while true
    Wait(5000, timerPort)
    print "TEST 1"
    print m.top.test
    print "TEST 2"
    m.top.test = createObject("roAssociativeArray")
    print "TEST 3"
end while
https://github.com/belltown/
0 Kudos
gabek
Level 7

Re: Accessing a m.top field a second time within a task seems to freeze the task

Good call on the loop.  In that particular case, I don't need every tick.

It seems my m.top issue seems to be linked to the previous execution of the timer writing to m.top.test, the main thread observing it, and firing off something that creates a roScreen.  If I don't allow a roScreen to be generated on execution #1 then #2 works just fine.

The first time the timer firesIs it possible that the next time the timer fires and tries to write to m.top.test that field is no longer available to the task thread, but is instead owned by the main thread or something?
0 Kudos
gabek
Level 7

Re: Accessing a m.top field a second time within a task seems to freeze the task

After some more testing, it seems to even be more simple than that.  As long as a roScreen is created, regardless of where or by who seems to break the task.  For instance, if I create a roScreen directly before starting the task makes the task not run at all.

I'm pretty sure this disclaimer has always been around for roScreen:
Once an roScreen is created, the display stack enters "Game Mode", and other screen components cannot be used.

But I'm not trying to make different screens active at the same time, just trying to make network requests within a task.  Is roScreen just not compatible with a ScreenGraph task at all?
0 Kudos
gabek
Level 7

Re: Accessing a m.top field a second time within a task seems to freeze the task

Due to me needing to go on with my life I'm just going back to the pre-task way of doing things Smiley Happy . Regular old async url requests from the main thread using the message port.  This bums me out since I really wanted to split everything off into tasks.  I guess I'll revisit once I get to the point of refactoring my roScreen to a SceneGraph node.
0 Kudos
Roku Employee
Roku Employee

Re: Accessing a m.top field a second time within a task seems to freeze the task

"gabek" wrote:
After some more testing, it seems to even be more simple than that.  As long as a roScreen is created, regardless of where or by who seems to break the task.  For instance, if I create a roScreen directly before starting the task makes the task not run at all.

I'm pretty sure this disclaimer has always been around for roScreen:
Once an roScreen is created, the display stack enters "Game Mode", and other screen components cannot be used.

But I'm not trying to make different screens active at the same time, just trying to make network requests within a task.  Is roScreen just not compatible with a ScreenGraph task at all?

Like i said in https://forums.roku.com/viewtopic.php?f=34&t=102584, i believe roScreen and roSgScreen are "immiscible" - like water and oil are; that is, you cannot expect the two to function at the same time. "Tasks" are part of roSgScreen components, so i would not expect them to work while roScreen is in command.
0 Kudos
gabek
Level 7

Re: Accessing a m.top field a second time within a task seems to freeze the task

Ah ha, this seems to be the piece that I wasn't aware of:

"Tasks" are part of roSgScreen components, so i would not expect them to work while roScreen is in command.

I had no idea that was the case, it wasn't clear.  But now I know!
0 Kudos