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

From: scott (scottw_at_[hidden])
Date: 2004-02-16 18:15:55

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Peter Dimov
> Sent: Tuesday, February 17, 2004 9:29 AM
> To: Boost mailing list
> Subject: Re: [boost] Re: Re: Future of threads (III)
> 
> 
> Sean Kelly wrote:
> > Peter Dimov wrote:
> >> Andreas Huber wrote:
> >>
> >>> I think he meant the object indirectly referenced by
> >>> boost::function:
> >>>
> >>> MyActiveObject pActive = new MyActiveObject();
> >>> boost::thread myThread( boost::function< void () >(
> >>>  boost::bind( &MyActiveObject::Run, pActive ) ) );
> >>> delete pActive;
> >>
> >> Why would anyone want to do that?
> >
> > What if MyActiveObject has interface methods that need to be
> > externally accessible?  Message queue endpoints, for 
> example.  Though
> > other program designs might obviate the need for such 
> access methods.
> 
> Yes, that's how I would answer my own question, too. It would 
> be interesting
> to see whether high-level components built on top of 
> boost::thread can solve
> the interthread communication problem in an elegant way. But 
> if we focus on
> the low-level layer, I think that this may be solved with a 
> thread::target()
> accessor (similar to the newly added function<>::target()).

Hoping you guys dont mind, but i have summarized some recent
messages WRT the original question.

Which was "is there room for 2?"

DG mentioned boost::threads. And you guys kinda sorted out how
to make an object equivalent to a thread (using boost::threads)?

This direction looks fine to me (we have platform independence).
I am assuming that the code that is presented for execution is
some kind of message queue processing and that that processing
results in calls to a method or methods in the "thread derived"
class? Something like this needs to happen (I think) if there is
going to be a class that has the appearance of running as an
independent thread.

This seems more confusing than it needs to be. So I'll wind it
back and try again.

I think that the concept of "class that is a thread" is a
compelling one. The Active Object pattern is a pretty damn
good formalization of what many people would tacitly understand
the concept to be.

I suspect that a small gap exists between that "tacit understanding"
and what we (i.e. you guys) have been working through. My best
identification of that gap goes like this...

An AO is something that comes into existence, certain events
are directed to it and it responds to them. This describes an
object that receives "work to do" over time. Work is not submitted
(in fact, cannot be) at ctor time.

So far we have a thread that can call a method within another
class, i.e. become the class.

Do you guys have any thoughts on how to "get work into" the
class (now that it is truly a running thread)? Cos this is
the essence of what an AO is. I think :-)

Cheers,
Scott