A very common concurrency pattern is to run a thread that performs a task at regular intervals. The thread that performs the task sleeps for the given interval then wakes up and performs the task. Lather, rinse, repeat... This pattern causes two problems. First, it is difficult to test the business logic of the task because the task itself is tightly coupled with the concurrency logic. Second, an exception raised while performing the task can cause the entire thread to abend. In a long-running application where the task thread is intended to run for days/weeks/years a crashed task thread can pose a significant problem. TimerTask alleviates both problems.
When a TimerTask is launched it starts a thread for monitoring the execution interval. The TimerTask thread does not perform the task, however. Instead, the TimerTask launches the task on a separate thread. Should the task experience an unrecoverable crash only the task thread will crash. This makes the TimerTask very fault tolerant. Additionally, the TimerTask thread can respond to the success or failure of the task, performing logging or ancillary operations.
One other advantage of TimerTask is that it forces the business logic to be completely decoupled from the concurrency logic. The business logic can be tested separately then passed to the TimerTask for scheduling and running.
A TimerTask supports two different types of interval calculations. A fixed delay will always wait the same amount of time between the completion of one task and the start of the next. A fixed rate will attempt to maintain a constant rate of execution regardless of the duration of the task. For example, if a fixed rate task is scheduled to run every 60 seconds but the task itself takes 10 seconds to complete, the next task will be scheduled to run 50 seconds after the start of the previous task. If the task takes 70 seconds to complete, the next task will be start immediately after the previous task completes. Tasks will not be executed concurrently.
In some cases it may be necessary for a TimerTask to affect its own execution cycle. To facilitate this, a reference to the TimerTask instance is passed as an argument to the provided block every time the task is executed.
The TimerTask class includes the Dereferenceable mixin module so the result of the last execution is always available via the #value method. Dereferencing options can be passed to the TimerTask during construction or at any later time using the #set_deref_options method.
TimerTask supports notification through the Ruby standard library Observable module. On execution the TimerTask will notify the observers with three arguments: time of execution, the result of the block (or nil on failure), and any raised exceptions (or nil on success).
Object references in Ruby are mutable. This can lead to serious problems when the Concern::Dereferenceable#value of an object is a mutable reference. Which is always the case unless the value is a Fixnum, Symbol, or similar "primitive" data type. Each instance can be configured with a few options that can help protect the program from potentially dangerous operations. Each of these options can be optionally set when the object instance is created:
:dup_on_deref When true the object will call the #dup method on the value object every time the #value method is called (default: false):freeze_on_deref When true the object will call the #freeze method on the value object every time the #value method is called (default: false):copy_on_deref When given a Proc object the Proc will be run every time the #value method is called. The Proc will be given the current value as its only argument and the result returned by the block will be the return value of the #value call. When nil this option will be ignored (default: nil)When multiple deref options are set the order of operations is strictly defined. The order of deref operations is:
:copy_on_deref:dup_on_deref:freeze_on_derefBecause of this ordering there is no need to #freeze an object created by a provided :copy_on_deref block. Simply set :freeze_on_deref to true. Setting both :dup_on_deref to true and :freeze_on_deref to true is as close to the behavior of a "pure" functional language (like Erlang, Clojure, or Haskell) as we are likely to get in Ruby.
Default :execution_interval in seconds.
60
Maintain the interval between the end of one execution and the start of the next execution.
:fixed_delay
Maintain the interval between the start of one execution and the start of the next. If execution time exceeds the interval, the next execution will start immediately after the previous execution finishes. Executions will not run concurrently.
:fixed_rate
FIXED_DELAY
Number of seconds after the task completes before the task is performed again.
Method to calculate the interval between executions.
Number of seconds the task can run before it is considered to have failed.
Create and execute a new TimerTask.
Execute a previously created TimerTask.
Create a new TimerTask with the given task and configuration.
Is the executor running?.
Adds an observer to this set.
Return the number of observers associated with this object.
Remove observer as an observer on this object so that it will no longer receive notifications.
Remove all observers associated with this object.
Return the value this object represents after applying the options specified by the #set_deref_options method.
As #add_observer but can be used for chaining.
Create a new TimerTask with the given task and configuration.
209 210 211 212 213
# File 'lib/concurrent-ruby/concurrent/timer_task.rb', line 209
def initialize(opts = {}, &task)
raise ArgumentError.new('no block given') unless block_given?
super
set_deref_options opts
end Instance Attribute Details #execution_interval ⇒ Fixnum
Returns Number of seconds after the task completes before the task is performed again.
259 260 261
# File 'lib/concurrent-ruby/concurrent/timer_task.rb', line 259
def execution_interval
synchronize { @execution_interval }
end #interval_type ⇒ Symbol
Returns method to calculate the interval between executions.
276 277 278
# File 'lib/concurrent-ruby/concurrent/timer_task.rb', line 276 def interval_type @interval_type end#timeout_interval ⇒ Fixnum
Returns Number of seconds the task can run before it is considered to have failed.
281 282 283
# File 'lib/concurrent-ruby/concurrent/timer_task.rb', line 281 def timeout_interval warn 'TimerTask timeouts are now ignored as these were not able to be implemented correctly' endClass Method Details .execute(opts = {}) {|task| ... } ⇒ TimerTask
Create and execute a new TimerTask.
252 253 254
# File 'lib/concurrent-ruby/concurrent/timer_task.rb', line 252
def self.execute(opts = {}, &task)
TimerTask.new(opts, &task).execute
end Instance Method Details #execute ⇒ TimerTask
Execute a previously created TimerTask.
235 236 237 238 239 240 241 242 243
# File 'lib/concurrent-ruby/concurrent/timer_task.rb', line 235
def execute
synchronize do
if @running.false?
@running.make_true
schedule_next_task(@run_now ? 0 : @execution_interval)
end
end
self
end #running? ⇒ Boolean
218 219 220
# File 'lib/concurrent-ruby/concurrent/timer_task.rb', line 218 def running? @running.true? end#add_observer(observer = nil, func = :update, &block) ⇒ Object Originally defined in module Concern::Observable
Adds an observer to this set. If a block is passed, the observer will be created by this method and no other params should be passed.
#count_observers ⇒ Integer Originally defined in module Concern::ObservableReturn the number of observers associated with this object.
#delete_observer(observer) ⇒ Object Originally defined in module Concern::ObservableRemove observer as an observer on this object so that it will no longer receive notifications.
Return the value this object represents after applying the options specified by the #set_deref_options method.
As #add_observer but can be used for chaining.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4