wns::ldk::CompoundHandlerInterface< CLASS > Struct Template Reference
[Compound Handler Interface]

Interface for the aspect of dealing with compounds.

#include <ldk/CompoundHandlerInterface.hpp>

Inheritance diagram for wns::ldk::CompoundHandlerInterface< CLASS >:

[legend]

Collaboration diagram for wns::ldk::CompoundHandlerInterface< CLASS >:

[legend]

List of all members.

Public Member Functions
virtual	~CompoundHandlerInterface ()
	Return true if you are willing to accept the given Compound.

---

Detailed Description

template<typename CLASS>
struct wns::ldk::CompoundHandlerInterface< CLASS >

Definition at line 63 of file CompoundHandlerInterface.hpp.

---

Constructor & Destructor Documentation

template<typename CLASS>

virtual wns::ldk::CompoundHandlerInterface< CLASS >::~CompoundHandlerInterface

(

)

[inline, virtual]

Functional units without internal memory delegate the isAccepting query to one of their lower functional units. On success, this results in a path through the layer, where each FunctionalUnit in the path promised to one of its upper functional units to accept the given Compound.
Each of the functional units in the path has to assure to deliver the Compound to the FunctionalUnit he asked using isAccepting. If it does not, chances are, that a Compound reaches a FunctionalUnit that has no internal storage and cannot be delivered further. That is an illegal state and can only be avoided if functional units conform to the above rule.
When paths of promises are created by recursively calling isAccepting, a FunctionalUnit may get asked to decide, whether it accepts a given Compound although the Commands that it builds its decision on, have not yet been activated. That, too, is illegal behaviour and can only be avoided by the careful placement of buffers. A buffer implementation for exactly this purpose is the Synchronizer. A FunctionalUnit such as the Synchronizer accepts compounds regardless of their content. This breaks chains of recursive isAccepting calls. That's fine Accept Compound from a higher FunctionalUnit. A higher FunctionalUnit delivers a Compound using doSendData. The higher FunctionalUnit asked for acceptance using isAccepting with the same Compound in advance.
It is the job of each FunctionalUnit to implement Compound delivery to lower functional units. Never call doSendData directly, always make shure that the FunctionalUnit is accepting the given Compound by calling isAccepting in advance. Your callback, when lower functional units may be accepting again. When there is no FunctionalUnit holding a Compound that it may deliver to its lower functional units, the net of functional units gets inactive. Only external events (other than defined by the ldk api) may trigger the functional units again:

• a top FunctionalUnit may receive a fresh Compound from outside the FunctionalUnit stack.
• a bottom FunctionalUnit may manage to deliver a Compound to the outside and thus change state to accept new compounds.
• any FunctionalUnit may change state through a timeout.
  Whenever a FunctionalUnit changes state from not accepting to accepting, it must inform its upper layers of the change using the wakeup method. Accept Compound from a lower FunctionalUnit in the incoming data flow. A lower FunctionalUnit delivers a Compound using doOnData.
  It is the job of each FunctionalUnit to implement Compound delivery to upper functional units. virtual functions -> virtual d'tor

Definition at line 151 of file CompoundHandlerInterface.hpp.

---

The documentation for this struct was generated from the following file:

• framework/library/src/ldk/CompoundHandlerInterface.hpp