![]() |
Scarab
v3.7.1
Project 8 C++ Utility Library
|
Base class for a cancelable object (i.e. an object that can be canceled by scarab::signal_handler or other client code) More...
#include <cancelable.hh>
Public Member Functions | |
cancelable () | |
cancelable (const cancelable &a_orig) | |
cancelable (cancelable &&a_orig) | |
virtual | ~cancelable () |
cancelable & | operator= (const cancelable &a_orig) |
cancelable & | operator= (cancelable &&a_orig) |
void | cancel (int a_code=0) |
asynchronous cancel function More... | |
void | reset_cancel () |
reset to non-canceled state More... | |
bool | is_canceled () const |
check canceled state More... | |
Protected Attributes | |
std::atomic< bool > | f_canceled |
Private Member Functions | |
virtual void | do_cancellation (int a_code) |
virtual void | do_reset_cancellation () |
Base class for a cancelable object (i.e. an object that can be canceled by scarab::signal_handler or other client code)
A cancelable object is one which has some execution operation that should be asynchronously cancelable. Cancellation is performed using cancelable::cancel().
For example, if the object of a derived class is executing in thread 1, client code in thread 2 or a signal (e.g. SIGINT) from the user or a system should be able to cancel execution.
If a derived class has a function execute() that performs the main execution loop, that loop should include a periodic check of cancelable::is_canceled() to know whether to exit the loop.
Any actions that should take place when cancelable::cancel() is used should be implemented by the derived class in do_cancellation().
Cancelable objects can exist within a parent/child hierarchy to ensure that execution can be cleanly shut down. Parent classes should implement do_cancellation(int) to cancel their children.
For example, if a parent object in thread 1 starts the execution of two children, each in their own thread (i.e. threads 2 and 3), then the parent object should be added to the signal_handler (using signal_handler::add_cancelable()). The parent's implementation of do_cancellation() should take care of calling cancelable::cancel() on each of the children. The children should not be separately added to the signal_handler.
Genreally it's assumed that a top-level-parent cancelable object will be created on the heap using std::shared_ptr (hence why signal_handler adds cancelables using std::shared_ptr<cancelable>).
Definition at line 51 of file cancelable.hh.
cancelable | ( | ) |
Definition at line 19 of file cancelable.cc.
cancelable | ( | const cancelable & | a_orig | ) |
Definition at line 23 of file cancelable.cc.
cancelable | ( | cancelable && | a_orig | ) |
Definition at line 27 of file cancelable.cc.
|
virtual |
Definition at line 33 of file cancelable.cc.
|
inline |
asynchronous cancel function
Definition at line 115 of file cancelable.hh.
|
privatevirtual |
Reimplemented in cancelable_wrapper.
Definition at line 54 of file cancelable.cc.
|
privatevirtual |
Definition at line 62 of file cancelable.cc.
|
inline |
check canceled state
Definition at line 129 of file cancelable.hh.
cancelable & operator= | ( | const cancelable & | a_orig | ) |
Definition at line 38 of file cancelable.cc.
cancelable & operator= | ( | cancelable && | a_orig | ) |
Definition at line 44 of file cancelable.cc.
|
inline |
reset to non-canceled state
Definition at line 122 of file cancelable.hh.
|
protected |
Definition at line 76 of file cancelable.hh.