RaftLib  0.3a
C++ Stream Processing Template Library
Public Member Functions | Static Public Member Functions | Protected Member Functions | Static Protected Member Functions | Protected Attributes | List of all members
Schedule Class Referenceabstract
Inheritance diagram for Schedule:
[legend]
Collaboration diagram for Schedule:
[legend]

Public Member Functions

 Schedule (Map &map)
 
virtual ~Schedule ()
 
virtual void start ()=0
 
virtual void init ()
 
void scheduleKernel (raft::kernel *const kernel)
 

Static Public Member Functions

static bool kernelRun (raft::kernel *const kernel, volatile bool &finished, jmp_buf *gotostate=nullptr, jmp_buf *kernel_state=nullptr)
 

Protected Member Functions

virtual void handleSchedule (raft::kernel *const kernel)=0
 

Static Protected Member Functions

static raft::kstatus checkSystemSignal (raft::kernel *const kernel, void *data, SystemSignalHandler &handlers)
 
static raft::kstatus quitHandler (FIFO &fifo, raft::kernel *kernel, const raft::signal signal, void *data)
 
static void invalidateOutputPorts (raft::kernel *kernel)
 
static bool kernelHasInputData (raft::kernel *kernel)
 
static bool kernelHasNoInputPorts (raft::kernel *kernel)
 

Protected Attributes

SystemSignalHandler handlers
 
kernelkeeper & kernel_set
 
kernelkeeper & source_kernels
 
kernelkeeper & dst_kernels
 

Constructor & Destructor Documentation

Schedule::Schedule ( Map map)

Schedule - base constructor takes a map object so that all sub-classes can access some of the map features through the schedule sub-class accessors.

Parameters
map- Map&

Here is the call graph for this function:

Schedule::~Schedule ( )
virtual

destructor, takes care of cleanup

nothing to do at the moment

Member Function Documentation

raft::kstatus Schedule::checkSystemSignal ( raft::kernel *const  kernel,
void *  data,
SystemSignalHandler handlers 
)
staticprotected

checkSystemSignal - check the incomming streams for the param kernel for any system signals, if there is one then consume the signal and perform the appropriate action.

Parameters
kernel- raft::kernel
data- void*, use this if any further info is needed in future implementations of handlers
Returns
raft::kstatus, proceed unless a stop signal is received

TODO, right now there is special behavior for term signal only, what should we do with others? Need to decide that.

Here is the call graph for this function:

void Schedule::init ( )
virtual

init - call to pre-process all kernels, this function is called by the map object befure calling start.

default, do nothing

bool Schedule::kernelHasInputData ( raft::kernel kernel)
staticprotected

kernelHasInputData - check each input port for available data, returns true if any of the input ports has available data.

Parameters
kernel- raft::kernel
Returns
bool - true if input data available.

only output ports, keep calling till exits

Here is the caller graph for this function:

bool Schedule::kernelHasNoInputPorts ( raft::kernel kernel)
staticprotected

kernelHasNoInputPorts - pretty much exactly like the function name says, if the param kernel has no valid input ports (this function assumes that kernelHasInputData() has been called and returns false before this function is called) then it returns true. kernel - raft::kernel*

Returns
bool - true if no valid input ports avail

assume data check is already complete

Here is the caller graph for this function:

bool Schedule::kernelRun ( raft::kernel *const  kernel,
volatile bool &  finished,
jmp_buf *  gotostate = nullptr,
jmp_buf *  kernel_state = nullptr 
)
static

kernelRun - all the logic necessary to run a single kernel successfully. Any additional signal handling should be handled by this function as its the only one that will be universally called by the scheduler.

Parameters
kernel- raft::kernel *const object, non-null kernel
finished- volatile bool - function sets to true when done.
Returns
true if run with no need for jmp_buf, false if the scheduler needs to run again with the kernel_state

must recheck data items again after port valid check, there could have been a push between these two conditional statements.

Here is the call graph for this function:

Here is the caller graph for this function:

raft::kstatus Schedule::quitHandler ( FIFO fifo,
raft::kernel kernel,
const raft::signal  signal,
void *  data 
)
staticprotected

quiteHandler - performs the actions needed when a port sends a quite signal (normal termination), this is most likely due to the end of data.

Parameters
fifo- FIFO& that sent the signal
kernel- raft::kernel*
signal- raft::signal
data- void*, vain attempt to future proof

NOTE: This should be the only action needed currently, however that may change in the futre with more features and systems added.

Here is the call graph for this function:

Here is the caller graph for this function:

void Schedule::scheduleKernel ( raft::kernel *const  kernel)

scheduleKernel - adds the kernel "kernel" to the schedule, ensures that it is run. Other than that there are no guarantees for its execution. It is purely virtual in its implementation. Before you drop in a kernel, it better be ready to go..all allocations should be complete.

Parameters
kernel- raft::kernel*

NOTE: The kernel param should be ready to rock, we just need to add it here. The data structures xx_kernels all expect a fully ready kernel, well the threads monitoring the system do at least and this is one. What we need to do to kick off the execution is add it to the handleSchedule virtual function which is implemented by each scheduler.

Here is the call graph for this function:

Here is the caller graph for this function:

virtual void Schedule::start ( )
pure virtual

start - called to start execution of all kernels. Implementation specific so it is purely virtual.

Implemented in pool_schedule, and simple_schedule.

Member Data Documentation

SystemSignalHandler Schedule::handlers
protected

signal handlers

kernelkeeper& Schedule::kernel_set
protected

kernel set


The documentation for this class was generated from the following files: