Inheritance diagram for smtk::realtime:

Public Member Functions | |
| int | block_signals (bool truth=true) |
| Don't block other signals while waiting. | |
| bool | destructor_error (void) |
| bool | is_invalid (void) const |
| see if the object is invalid | |
| bool | is_valid (void) const |
| see if the object is valid | |
| realtime (long sec, long usec) | |
| realtime (float period) | |
| realtime (double period) | |
| realtime (long double period) | |
| int | wait (void) |
| wait until the period | |
| virtual | ~realtime (void) |
Protected Member Functions | |
| template<class T> | |
| T | invalidate (T t) |
| invalidate the object | |
| void | invalidate (void) |
| invalidate the object | |
| template<class T> | |
| T | validate (T t) |
| validate the object | |
| void | validate (void) |
| validate the object | |
Examples: realtime_1.cpp.
This is much more efficient than putting usleep(3)'s in you code. By setting the processes interval timer once (which the smtk::realtime constructor does) and calling smtk::realtime::wait() you can make your program run in periodic intervals. The average interval period is pretty constant, but the interval period will be off by amounts that about the size of the timer resolution that your system provides. You can run smtk_realtime_test to see how well your computer keeps accurate time intervals.
If you have a simulation that requires a fixed time-step you will have to choose the same or smaller period for the interval timer then the time step that the simulation requires, and then skip calculations in some intervals depending on the wall clock time. The smaller interval timer period, where you to see if it's time to calculate again, the less latency you will add between the simulation and the output (operator display).
There can be only one instance of a smtk::realtime object because there is only one REAL-TIME (ITIMER_REAL) interval timer per process, at least on the GNU/Linux OS.
This is built with setitimer(2), sigaction(2), sigsuspend(2), and sigprocmask(2), and uses signal SIGALRM on GNU/Linux. Don't use this in combination with sleep(3), usleep(3), or mess with signal SIGALRM which this is using.
| realtime::~realtime | ( | void | ) | [virtual] |
If you inherit this class keep in mind that there can only be one instance of this class. That's because there is only one REAL-TIME (ITIMER_REAL)timer per process on most OS's.
| realtime::realtime | ( | long double | period | ) |
If this fails to get an system interval timer the object will be made invalid so that is_invalid() will return true, and smtk::spw at level ERROR.
| period | is the period of the interval timer in seconds. |
| realtime::realtime | ( | double | period | ) |
If this fails to get an system interval timer the object will be made invalid so that is_invalid() will return true, and smtk::spw at level ERROR.
| period | is the period of the interval timer in seconds. |
| realtime::realtime | ( | float | period | ) |
If this fails to get an system interval timer the object will be made invalid so that is_invalid() will return true, and smtk::spw at level ERROR.
| period | is the period of the interval timer in seconds. |
| realtime::realtime | ( | long | sec, | |
| long | usec | |||
| ) |
If this fails to get an system interval timer the object will be made invalid so that is_invalid() will return true, and smtk::spw at level ERROR. Until portability issue bite us will stick with using two longs as parameter arguments. Use the other constructors if your worried about this interface changing.
| sec | is the number of seconds in the period. This can be added to millionth times the number of microseconds in usec to determine the period in seconds. | |
| usec | is the number of microseconds in the period. One millionth of this can be added to the number of seconds in sec to determine the period in seconds. |
| int realtime::block_signals | ( | bool | truth = true |
) |
Don't block other signals while waiting.
This could be handy if you have a program that will wait a long time (period is large) and you wish to make it more responsive to signals.
| truth | If truth is true this sets things up so that signals other than SIGALRM get blocked while a call to realtime::wait() is waiting. The default is to have other signals blocked while a call to realtime::wait() is waiting when the period is less than one second (< 1.0) and signals other than SIGALRM don't get blocked while a call to realtime::wait() is blocking when the period is greater than or equal to one second (>= 1.0). The other signals are from the current signal process mask at the time this is called. So if you change the current signal process mask you'll need to call this again if you like this class to use it. |
| bool realtime::destructor_error | ( | void | ) |
Because SmTk don't like to throw exceptions so much, and smtk::realtime::~realtime() makes a few system calls, you can use this to check if there was an error when calling smtk::realtime::~realtime(). It's not necessary to check for this error in your code if your program is just going to exit after calling smtk::realtime::~realtime(), like in the case when the you have statically declared object and it goes out of scope.
| T smtk::validation::invalidate | ( | T | t | ) | [inline, protected, inherited] |
invalidate the object
Make the object invalid.
| void smtk::validation::invalidate | ( | void | ) | [inline, protected, inherited] |
invalidate the object
Make the object invalid.
| bool smtk::validation::is_invalid | ( | void | ) | const [inline, inherited] |
see if the object is invalid
| bool smtk::validation::is_valid | ( | void | ) | const [inline, inherited] |
see if the object is valid
| T smtk::validation::validate | ( | T | t | ) | [inline, protected, inherited] |
validate the object
Make the object valid.
| void smtk::validation::validate | ( | void | ) | [inline, protected, inherited] |
validate the object
Make the object valid.
| int realtime::wait | ( | void | ) |
1.5.2