gabek
Visitor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-25-2017
05:49 PM
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:
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.
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!
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!
6 REPLIES 6
belltown
Roku Guru
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-25-2017
06:55 PM
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
gabek
Visitor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-27-2017
04:24 PM
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?
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?
gabek
Visitor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-27-2017
05:49 PM
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:
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?
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?
gabek
Visitor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-27-2017
08:18 PM
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 🙂 . 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.
NB_
Roku Guru
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-28-2017
02:19 PM
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.
gabek
Visitor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-28-2017
02:40 PM
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:
I had no idea that was the case, it wasn't clear. But now I know!
"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!