#include <domprocessor.h>
Inheritance diagram for Geddei::DomProcessor:
Public Member Functions | |
const bool | createAndAddWorker (const QString &host, const uint key) |
const bool | createAndAddWorker () |
DomProcessor (const QString &primaryType) | |
DomProcessor (SubProcessor *primary) | |
void | ratify (DxCoupling *c) |
virtual | ~DomProcessor () |
Friends | |
class | DxCoupling |
class | SubProcessor |
SubProcessor derived objects have no method of direct control; DomProcessor acts as the interface for using SubProcessor objects in this respect.
Becuase DomProcessor objects have no inate profession, they require a SubProcessor object at construction time. This may be provided by either a pointer to an instance (easiest in an development scenario), or by a string describing the SubProcessor's type which the SubProcessor factory can create (most useful in a release scenario with plugins abound). This object is forever after refered to as the /primary/ SubProcessor object.
There are two main advantages with coding in the Sub/DomProcessor paradigm, both of these are due to the constraints attached to the SubProcessor, in that it is stateless. The first is the extra simplicity afforded in coding it. The second is that it may be implicitly parallelised. This means, in essence, that a DomProcessor may have not just one but many SubProcessor objects working under it. Each of these SubProcessor objects are refered to as /workers/.
This has significant and interesting repercussions in environments where multiple CPUs are available or multiple machines may be accessed.
In the current API the SubProcessor objects cannot (and should not) be accessed exclusively once under the control of a DomProcessor. So they cannot be deleted explicitly. The DomProcessor object essentially owns the SubProcessors and will take care of any deletions that must happen at the end of its lifetime.
Three methods are available for introducing extra SubProcessor objects to a DomProcessor; addWorker(), and two forms of createAndAddWorker. addWorker() allows the developer to control the creation process of the SubProcessor, the other two are "easier" since they will automatically create the SubProcessor for you, using the SubProcessorFactory. This, of course, only works if the SubProcessor class you have constructed the DomProcessor with is available as a plugin. If not you'll just have to use addWorker.
Geddei::DomProcessor::DomProcessor | ( | SubProcessor * | primary | ) |
Constructor. A valid primary SubProcessor must be passed in primary. This is to determine the type of DomProcessor, and provide at leat one worker.
primary | The primary SubProcessor object. This must be valid. |
Geddei::DomProcessor::DomProcessor | ( | const QString & | primaryType | ) |
Constructor. Creates a new SubProcessor object of type given, then initialises DomProcessor as a primary of this type (to provide at least one worker).
primaryType | A valid and factory-creatable type of SubProcessor. |
Geddei::DomProcessor::~DomProcessor | ( | ) | [virtual] |
Default destructor.
const bool Geddei::DomProcessor::createAndAddWorker | ( | const QString & | host, | |
const uint | key | |||
) |
Creates and adds a remote SubProcessor to this Processor's list of workers. Uses a DR/RSCoupling for the connection (a remote TCP/IP link).
host | The host on which the SubProcessor should be added. This must be running the Geddei nodeserver. | |
key | The session key under which the SubProcessor will be added. |
const bool Geddei::DomProcessor::createAndAddWorker | ( | ) |
Creates and adds a local SubProcessor to this Processor's list of workers. Uses SubProcessorFactory for the creation, and the primary for the type.
Uses a DSCoupling for the connection (an efficient local shared memory link).