The Nimator.TickSafe() implementation is typically called on a timer (just like the example console app does). However, the checks that are configured possibly take longer than the timer interval, causing monitoring cycles to be fired more quickly than they can be finished. This is obviously a problem.
Although it can be argued that this problem should be solved in the calling application that has the timer, it also makes sense to have a more robust framework in this regard. Some possibilities would include:
Throwing an exception from TickSafe whenever a previous call is still in progress;
Syncrhonize all calls to TickSafe by blocking subsequent calls until the previous ones finish;
Aborting a previous TickSafe with an exception and/or failed result whenever a new call is started when an old one is still in progress;
Log a Warning if a new call is started when old calls are still in progress;
Etc.
At any rate, this is something that should possibly be handled by the framework.
The
Nimator.TickSafe()implementation is typically called on a timer (just like the example console app does). However, the checks that are configured possibly take longer than the timer interval, causing monitoring cycles to be fired more quickly than they can be finished. This is obviously a problem.Although it can be argued that this problem should be solved in the calling application that has the timer, it also makes sense to have a more robust framework in this regard. Some possibilities would include:
TickSafewhenever a previous call is still in progress;TickSafeby blocking subsequent calls until the previous ones finish;TickSafewith an exception and/or failed result whenever a new call is started when an old one is still in progress;At any rate, this is something that should possibly be handled by the framework.