20,741
edits
FlightGear Newsletter January 2014: Difference between revisions
Jump to navigation
Jump to search
m
FlightGear Newsletter January 2014 (view source)
Revision as of 05:24, 1 February 2014
, 1 February 2014→Behind the Scenes of: Nasal Loops
Philosopher (talk | contribs) |
|||
| Line 34: | Line 34: | ||
Nasal has several ways to implement an iteration, including repeated events run from listeners or timers. | Nasal has several ways to implement an iteration, including repeated events run from listeners or timers. | ||
A polling loop, run via a timer, 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. | A polling loop, run via a timer, 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, whereas timers are run often, pretty much regardless of external events. Both are triggered by calling a so-called "callback" - which is just a provided function to be called. | The setlistener API is intended to catch rare events, whereas timers are run often, pretty much regardless of external events. Both are triggered by calling a so-called "callback" - which is just a provided function to be called, i.e. the funcction specifies what is to be done once the event is triggered. | ||
In general, timers are not bad or expensive, because it really depends on what you're doing inside the, but some constructs benefit from listeners. Any callback will be executed within a single frame normally - so a long-running timer will add up to the frame spacing, as will a listener triggered just as often or even multiple times per frame. It doesn't matter if the code/callback is run inside a timer or a listener - what | In general, timers are not bad or expensive, because it really depends on what you're doing inside the callback (function) that is called, but some constructs benefit from listeners. | ||
Any callback will be executed within a single frame normally - so a long-running timer will add up to the frame spacing (latency), as will a listener triggered just as often or even multiple times per frame. | |||
It doesn't matter if the code/callback is run inside a timer or a listener - what matters is the complexity of the code that runs. Ultimately, though, some code has to be executed somewhere to get the desired result, but in most cases that code can be simple rather than complex. Listeners are only really preferable over timers when it comes to checking for some condition, because timer-loop-based polling is called "busy-waiting", i.e. more expensive, see the previous analogy of somebody having to do something regularly in order to perform a check. | |||
A listener on the other hand, is not resource-hungry while it is "waiting", it's not even "busy" - it's just not doing anything until it is "fired" (analogous to Interrupt Service Routines, i.e. a smoke detector firing an alarm once it detects smoke). However, there are often times where loops make a lot of sense, mainly when lots of values of properties need to be used to drive or evaluate a subsystem or equation. | |||
Continue reading at [[Nasal Loops]]... | Continue reading at [[Nasal Loops]]... | ||