-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org]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