Callbacks: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 30: Line 30:


== Timers ==
== Timers ==
{{Merge|Listeners}}
'''Timers''' are a way to register recurring tasks to be executed repeatedly. This is accomplished using the FlightGear event manager. Timers are the most common method for running Nasal callbacks (functions), the other being [[Listeners]].
Please noote that that settimer() should be considered deprecated, and maketimer() should be favored instead.


* [[Nasal Callbacks Explained]]
 
"events" in the performance monitor can usually be attributed to Nasal timers, Nasal is not the only subsystem to use the event manager
 
there's basically a separate "events" subsystem which is based on FGTimer/SGTimer objects that trigger callbacks - in this case, Nasal callbacks. This can also be seen in the system monitor: http://wiki.flightgear.org/Howto:Use_the_system_monitor
 
the settimer() and setlistener() APIs are particularly tedious to manage properly - but the de facto practice is to use those as the main building blocks to write/integrate full subsystems into the FlightGear main loop - tiny coding errors may not have much of an effect, but under certain circumstances, those coding errors will add up (i.e. over time), so that the original "task" of checking your inbox once per hour, ends up being executed hundreds of times per second - the underlying code would still be correct though, it's just the event handling code that is not written correctly, which is often the case when using reset/re-init or when changing locations
 
In a sense, timers are "active" - while listeners are "passive", because they get only ever invoked once the property is modified. Still, the reason for using timers is usually saving resources - by running certain code at configurable intervals.
 
In other words, there are subsystems that run Nasal code, without showing up in the Nasal category - such as property tree or events system.
Still, that doesn't currently tell you which code (function, loop, file, line number etc) is really adding up/expensive.
 
the event manager subsystem (SGEventMgr) which has two internal "queues" for keeping a list of callbacks that shall be invoked when a certain event (timeout) happens, as well as the property tree interface to register Nasal callbacks via the SGPropertyChangeListener API:
 
http://api-docs.freeflightsim.org/simge ... ntMgr.html
http://api-docs.freeflightsim.org/simge ... tener.html
 
* [[Howto:Timers and properties]]

Revision as of 17:55, 20 February 2016

In FlightGear, a callback is a function that will typically be invoked by either a Timers or a property Listeners

Listeners

Listeners are a way to register event handlers to be executed once a property is modified/written to (updated). This is accomplished using the SGProeprtyChangeListener API (link) in SimGear. Listeners are the most common method for running custom Nasal callbacks (functions), the other being Timers.

many subsystems are modifyinig properties, which may in turn invoke Nasal callbacks (possibly even without being aware of the implications).

the settimer() and setlistener() APIs are particularly tedious to manage properly - but the de facto practice is to use those as the main building blocks to write/integrate full subsystems into the FlightGear main loop - tiny coding errors may not have much of an effect, but under certain circumstances, those coding errors will add up (i.e. over time), so that the original "task" of checking your inbox once per hour, ends up being executed hundreds of times per second - the underlying code would still be correct though, it's just the event handling code that is not written correctly, which is often the case when using reset/re-init or when changing locations

In a sense, timers are "active" - while listeners are "passive", because they get only ever invoked once the property is modified. Still, the reason for using timers is usually saving resources - by running certain code at configurable intervals.

In other words, there are subsystems that run Nasal code, without showing up in the Nasal category - such as property tree or events system. Still, that doesn't currently tell you which code (function, loop, file, line number etc) is really adding up/expensive.

Cquote1.png Listeners should be used on properties to get notice about occasional changes. In cases where we *know* when the property changes -- once per loop or more often -- we can have the same result cheaper with a loop. (Listeners on YASim properties are special in that those can change several times per frame, and one may indeed want the listener triggered every time. But this should be a deliberate decision, not an accident.) For some of your listeners it may be enough to set the second optional argument to 0, so that the listener code is only triggered when the node value changes. Just turn on listener logging or put a print() message into it to see the costs.
— Melchior FRANZ (Oct 24th, 2007). Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes.
(powered by Instant-Cquotes)
Cquote2.png

Timers

Merge-arrows.gif
It has been suggested that this article or section be merged with Listeners.

Timers are a way to register recurring tasks to be executed repeatedly. This is accomplished using the FlightGear event manager. Timers are the most common method for running Nasal callbacks (functions), the other being Listeners. Please noote that that settimer() should be considered deprecated, and maketimer() should be favored instead.


"events" in the performance monitor can usually be attributed to Nasal timers, Nasal is not the only subsystem to use the event manager

there's basically a separate "events" subsystem which is based on FGTimer/SGTimer objects that trigger callbacks - in this case, Nasal callbacks. This can also be seen in the system monitor: http://wiki.flightgear.org/Howto:Use_the_system_monitor

the settimer() and setlistener() APIs are particularly tedious to manage properly - but the de facto practice is to use those as the main building blocks to write/integrate full subsystems into the FlightGear main loop - tiny coding errors may not have much of an effect, but under certain circumstances, those coding errors will add up (i.e. over time), so that the original "task" of checking your inbox once per hour, ends up being executed hundreds of times per second - the underlying code would still be correct though, it's just the event handling code that is not written correctly, which is often the case when using reset/re-init or when changing locations

In a sense, timers are "active" - while listeners are "passive", because they get only ever invoked once the property is modified. Still, the reason for using timers is usually saving resources - by running certain code at configurable intervals.

In other words, there are subsystems that run Nasal code, without showing up in the Nasal category - such as property tree or events system. Still, that doesn't currently tell you which code (function, loop, file, line number etc) is really adding up/expensive.

the event manager subsystem (SGEventMgr) which has two internal "queues" for keeping a list of callbacks that shall be invoked when a certain event (timeout) happens, as well as the property tree interface to register Nasal callbacks via the SGPropertyChangeListener API:

http://api-docs.freeflightsim.org/simge ... ntMgr.html http://api-docs.freeflightsim.org/simge ... tener.html