-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org]On Behalf Of Matthew Vogt Sent: Tuesday, February 17, 2004 2:51 PM To: boost@lists.boost.org 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