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

From: scott (scottw_at_[hidden])
Date: 2004-02-16 22:05:48

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Matthew Vogt
> Sent: Tuesday, February 17, 2004 2:51 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: Future of threads (III)
> 
> 
> Jeff Garland <jeff <at> crystalclearsoftware.com> writes:
> 
> > > This is an interesting idea, using the boundaries of objects as 
> > > the interaction points between threads.  I have no experience 
> > > with this sort of threading, but your comments led me to sketch 
> > 
> > Interestingly, neither do I -- other than being aware of 
> the ideas and having
> > looked at how it might be applied.  I never found an 
> application where this
> > made more sense than thread pools or some other more 
> pedestrian threading
> > model...
> 
> Do you know what classes of apps use the active object 
> pattern?  The example
> in the Douglas Schmidt paper doesn't really provide much 
> explanation for
> why you might want active local objects.

erm not entirely sure of what constitutes an "active object app"
but what the hey! here's my best shot.

imagine a distributed system that needs a db server. or more accurately
the system needs an implementation of a specific data model that
supports the operation of the system. an "interface" needs to
be available. this interface must be able to cope with requests
from multiple threads, it must be asynchronous (does not block
clients) as anything else would be create a terminal bottleneck.

it would seem quite natural for the "interface" to be an
active object, accepting requests from multiple client threads
and returning results as they become available. at the very least
the "interface" (active object) should be a distinct thread.
internally there may be more threads processing the actual
db queries (whatever is optimal for the underlying db i/f).

imagine there is more than the one data model. or imagine that
the distributed system must integrate with an external system.
the external system would itself be running according to some
operational model.

this would seem to require a multiplicity of active objects.

while this example might characterize active objects as something
relevant to larger developments i think that the pattern can
be applied within a single desktop app. i would guess that the
internals of ms word would be pretty substantial. and maybe an
active object that encapsulates all access to the registry (persistent
store) would be a nice way to engineer things.

for a last, desparate shot; i have personally been involved
in several telephony developments that simply would not have
completed without active object thinking.

hope this was what you were wondering about...

> 
> > 
> > All I can say is wow and very impressive!  I believe you 
> have managed to
> > leverage the power of several boost libraries very nicely.

yes. this code has legs!

cheers,
scott