FlightGear Newsletter January 2014: Difference between revisions

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.

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.

 

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 matter 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 timerloop-based polling is called "busy-waiting", i.e. more expensive, see the previous analogy. A listener on the other hand when it is "waiting" is not resource-hungry, it's not even busy - it's just not doing anything until it is "fired". 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.