20,741
edits
Nasal Loops: Difference between revisions
m
http://forum.flightgear.org/viewtopic.php?f=30&t=21886&p=198656&hilit=file+nasal+timers#p198644
m (Use Nasal highlighter) |
m (http://forum.flightgear.org/viewtopic.php?f=30&t=21886&p=198656&hilit=file+nasal+timers#p198644) |
||
| Line 2: | Line 2: | ||
Nasal has several ways to implement an iteration. | Nasal has several ways to implement an iteration. | ||
A polling loop is akin to somebody permanently running to a room to check if the lights are on - a listener is like somebody being INSIDE the room SLEEPING and only WAKING up once the lights are turned on. | |||
The setlistener API is intended to catch rare events. Avoid complex loops if you don't have to. | |||
In general, "loops" are not bad or expensive, it really depends on what you're doing inside the loop. | |||
A loop will be executed within a single frame normally - so a long-running loop will add up to the frame spacing. | |||
There's nothing magic about timers or listeners - they can just as well inflate your frame spacing. | |||
It doesn't matter if the code/callback is run inside a loop, timer or a listener - what matter is the complexity of the code that runs. | |||
timers or listeners are only really preferable over loops when it comes to checking for some condition, because polling is called "busy-waiting", i.e. more expensive, see my previous analogy. | |||
A listener or timer "waiting" is not resource-hungry, it's not even busy - it's not doing anything until it is "fired". | |||
Regarding setprop/getprop - they're not as bad as we used to think - in fact, Thorsten has shown that they're preferable over most props.nas APIs, this may however change once the whole thing is replaced with cppbind bindings. | |||
Well loops aren't bad necessarily: they can be used in a less-than-optimal manner, but there are often times where they make a lot of sense. Some pros and cons of both: | |||
Listeners: Pros: | |||
* Can be used to receive instant "notifications" (events), avoiding unnecessary gets, | |||
* Really useful for Updating another property based on changes in one - like a mirror that scales by a factor, or something. (It's kinda a pity we can't just redirect read/writes... That's something I haven't explored enough, since it's various parts of C++) | |||
Listeners: Cons: | |||
* Each event is run in the same code as the event that triggers it (aka the setting-a-property code calls the event), so each event is run in the same thread and has the possibility to block the parent - which is probably not a good idea, so listeners should generally run as little code as possible. Note however that, depending on the property, it's all going to get run inside the main loop anyway - so it's no different than loops (roughly speaking). | |||
* May be run several times per frame. | |||
* Little more abstract and prone to danger than loops; you do not always know what listeners are registered where, and any listener that writes to a different property has the potential to infinitely call each other and thus segfault. (Unless you make guards on your listener against this... which is possible, but requires some work.) | |||
Loops: Pros: | |||
* Very useful for running loop-like tasks - e.g. something that updates regularly, particularly if it looks at many properties, or if it changes even if the dependent-upon property(s) are not updated. | |||
* Run once a frame at max – which is the fastest the user will see the changes anyway. | |||
Loops: Cons: | |||
* However, they are run at the end (IIRC) of the frame, so if you need instant reaction (i.e. interaction back and forth with another subsystem via properties), loops won't be quick enough, and thus listeners would be required. | |||
== for, while, foreach, and forindex loops == | == for, while, foreach, and forindex loops == | ||