[boost] [Threads] Reactive Objects

From: scott (scottw_at_[hidden])
Date: 2004-03-01 17:49:50

Hi,

I have been working on a small library that has become
reasonably useful and possibly of interest to someone else.
It's also become fairly large.

I am quite interested in this library getting "boosted" but
even given that there is substance to the library its scope
is a bit of a problem; its quite large. It was started as
a project with requirements very similar to those associated
with the ActiveObject pattern;

http://citeseer.nj.nec.com/lavender96active.html
(reference from J. Garland)

and takes many cues from the concepts and primitives found
in SDL;

http://www.sdl-forum.org/

Its possible to characterize this library as the basic
building blocks for clean, robust multi-threading <ahem>. It
could also be characterized as a subset of TAO, i.e. CORBA.
While its a very small subset <sheepish grin>, maybe these
comments gives scale to the scope issue.

A breakdown of the incidental technologies tackled by
this library follows;

* multi-threading building block classes
* network representation of structured data (variants)
* saving and loading of network data (persistence)
* interactive machines (inter-thread messaging)
* stateless and stateful machine representation
* code generation of network data and machine skeletons
* message forwarding (distributed messaging)
* transparent remote machines (proxies for inter-process messaging)
* support for multiple encodings, e.g. binary, text, XML...

To flesh this list out into something less opaque, a set
of file fragments follows. These are the result of applying
the library to the test case pushed around in the recent
thread "Simple Active Object". They are necessarily abbreviated;

// ---------------------------------
// db_server.tms (the schema)
//

record configuration {			// Persistent portion of the db_server
        string data_source
        integer maximum_workers
        integer maximum_clients
}

record open {}		// Messages between the server and its clients
record close {}
record select {
        string sql_statement
}
record busy {}

state	INTIAL,		// Pre-defined
        READY,		// Normal operation
        OVERLOADED,		// All workers busy
        OUT_OF_SERVICE	// Something went wrong

// Define the messages expected in the
// different states

transition INITIAL	void		// Standard startup

transition READY		open,			// Another client connecting
                                close,		// Client closing
                                configuration,	// Reconfiguration
                                select		// An SQL select statement
..

// ---------------------------------
// db_server.h (auto-generated header)
//
..

#define db_server_configuration_hash	0x03493ac9
#define db_server_open_hash			0x7a6ffa00
#define db_server_close_hash			0x1093ac66
#define db_server_select_hash			0x004410ac
#define db_server_busy_hash			0x74529711

struct typed03493ac9
{
        ..
        string &data_source;
        long &maximum_workers;
        long &maximum_clients;
        ..
};

struct db_server
{
        ..
        enum { INITIAL, READY, OVERLOADED, OUT_OF_SERVICE };

        typedef typed03493ac9 configuration;
        typedef typed7a6ffa00 open;
        typedef typed1093ac66 close;
        typedef typed004410ac select;
        typedef typed74529711 busy;

        virtual int transition( typed_state<INITIAL> ) = 0;	// void message
        virtual int transition( typed_state<READY>, typed_bind<open> & ) = 0;
        virtual int transition( typed_state<READY>, typed_bind<close> & ) = 0;
        virtual int transition( typed_state<READY>, typed_bind<configuration> & ) =
0;
        virtual int transition( typed_state<READY>, typed_bind<select> & ) = 0;

        int machine( typed_word & );		// The auto-generated switch statements
        ..
};
..

// ---------------------------------
// my_server.cpp (application declaration of db_server)
//

#include "db_server.h"

class my_server : public state_machine<db_server>
{
        typed_memory_folder home;
        db_server configuration;
        address_group client;

        virtual int transition( typed_state<INITIAL> );
        virtual int transition( typed_state<READY>, typed_bind<open> & );
        ..
};

// my_server.cpp (application definition of db_server)
//

my_server::my_server() :
home( "configuration\\my_server" )
{
        try	// Persistence
        {
                load( home, configuration );	// Recover previous image
        }
        catch( ... )
        {
                // Not found. Set factory defaults

                configuration.data_source	= "";
                configuration.maximum_workers	= 4;
                configuration.maximum_clients	= 100;

                save( home, configuration );
        }
}

int
my_server::transition( typed_state<INITIAL> )
{
        if( data_source.empty() )
        {
                return OUT_OF_SERVICE;
        }
        if( ... )	// Attempt to connect to RDBMS
        {
                return READY;
        }
        return OUT_OF_SERVICE;
}

int
my_server::transition( typed_state<READY>, typed_bind<open> &s )
{
        client.insert( sender() );
        reply( configuration );
}
..

int
my_server::transition( typed_state<READY>, typed_bind<select> &s )
{
        if( ... )	// Find an idle worker
        {
                // Submit request to worker
                ..

                return READY;
        }
        reply( busy() );

        return READY;
}

Hopefully these fragments have been enough to sketch out the
intent of the library and where it currently is "at". As a bunch
of materials, it is a .lib, headers and a .exe (the schema parser+generator)
There are (serious) pretentions to platform independence but current
materials are for Windows.

I am very happy to work towards a boosted version of a subset of
this work cos basically it seems too large to be a prospect
otherwise. This subset would be in the area of mutli-threading
building block classes, i.e. an "alternate threading model". However,
after the recent exchange of related and interesting messages, I felt
compelled to "come clean" with some background.

So, to Matthew and Mark. Are you interested in dicsussing the possible
implementation of;

* simple active objects (completion of current alternate threading model)
* simple reactive objects (completion of current with two-way calling of
methods)
* something else?

Cheers,
Scott