Geddei::DomProcessor Class Reference
[Geddei's core classes.]

The Processor-derived class for handling SubProcessor objects. More...

#include <domprocessor.h>

Inheritance diagram for Geddei::DomProcessor:

Inheritance graph
[legend]
Collaboration diagram for Geddei::DomProcessor:

Collaboration graph
[legend]
List of all members.

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

Detailed Description

The Processor-derived class for handling SubProcessor objects.

Author:
Gav Wood <gav@cs.york.ac.uk> DomProcessor can be thought of as a generic Processor class which is specialised not at compile time but at runtime. It is publicly derived from the Processor class and thus contains all the public Processor methods as you might expect, however they are written so that a SubProcessor object can be "plugged in" to it in order to cement the specialisation.
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.


Constructor & Destructor Documentation

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.

Parameters:
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).

Parameters:
primaryType A valid and factory-creatable type of SubProcessor.

Geddei::DomProcessor::~DomProcessor (  )  [virtual]

Default destructor.


Member Function Documentation

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).

Parameters:
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.
Returns:
true iff a worker was 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).

Returns:
true iff a worker was added.


The documentation for this class was generated from the following files:
Generated on Fri Nov 10 21:58:32 2006 for Exscalibar by  doxygen 1.5.1