RE: [boost] Re: Future of threads (III)

From: scott (scottw_at_[hidden])
Date: 2004-02-18 14:08:59

> [mailto:boost-bounces_at_[hidden]]On Behalf Of David Abrahams

> 
> Hmm, thank goodness that emacs/gnus has a "Capitalize" key command
> for messages like this one.  Sadly, it didn't fix everything ;-)

Too much time spend in ksh perhaps.

> 
> Are ActiveObjects like all objects were in Simula: each running in its
> own thread, with fully asynchronous inter-object communications?

There were a few responses to your question. This is in response to
those as well.

I can't make comparisons with Simula as I have never used it. But the
short answer to your question is "no". An ActiveObject may "equate to"
(sorry, can't think of a better term) one thread or no thread.

struct servant_base
{
        virtual void operator()( signal & ) = 0;
};

struct scheduler_base : public servant_base
{
        std::deque<signal> pending;

        void receive( signal & );

        virtual void operator()( signal & ) = 0;
};

struct threaded_active_object : public scheduler_base
{
        virtual void operator()( signal & )
        {
        }};

struct unthreaded_active_object : public servant_base
{
        virtual void operator()( signal & )
        {
        }
};

The scheduler_base class is the one that needs to fire up
a boost::thread. The code that executes will detect inbound
signals (arriving via "receive") and remove them from
"pending". Then there is a "dispatch" function (all described
in the pattern) that arranges for the operator() call on
the proper servant_base-derived instance, passing a signal.

The ActiveObject whose code is eventually executed may be
a servant-derived or scheduler-derived.

So, my only deviation from other responses is to do with
the statement that ActiveObjects can "equate to" many
threads. In my (comfortable but shrinking) world, an
ActiveObject may manage subordinate ActiveObjects
that are scheduler-derived and in this indirect sense
"equate to" multiple threads. But a class deriving from
servant_base (possibly via scheduler) is a zero-or-one-
thread-class.

cheers,
sCOtT
:-)