From: Sean Kelly (sean_at_[hidden])
Date: 2004-02-17 01:21:34
scott wrote:
>
> 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.
I agree. The object model has always made more sense to me in this case
as the thread and executing object code seem tightly bound. I do
sometimes use a "job queue" however, that's sort of a fancy thread pool
which uses job objects much like the Boost design. This was really
designed for short-term or fire-and-forget tasks however.
> 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.
If a person is creating an object that is going to be executed as a
thread, he must do so deliberately. Synchronization points must be
considered, etc. To me, the inheritance model more accurately
communicates the purpose of such a design than does the Boost model.
but it also assumes that the object *is* a thread rather than that it
can be used in an asynchronous fashion. I think there are definite
applications for both designs.
> 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.
Another model that suits this design is a pool of anonymous worker
threads, though it's perhaps conceptually a bit less obvious. With that
model, you have a bunch of threads that pull tasks of a job queue and
process them. State information is stored as part of the message or by
some other means. IOCP is a perfect example of this.
> 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 :-)
Depends on the application, I suppose :) I wrote a comm. framework a
few years ago that makes fairly heavy use of proxy objects and
callbacks. Some other applications may be simpler and just expose
methods directly on the subclassed thread object.
Sean