[boost] Re: Future of threads (III)

From: Matthew Vogt (mvogt_at_[hidden])
Date: 2004-02-17 18:49:08

scott <scottw <at> qbik.com> writes:

> 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).
> 

Yeah, this makes sense to me.  Jeff's telephony example also seems to fit
conceptually; I think the degree to which an Active Object (TM) perspective
fits a given task depends on the granularity of the objects, and the 
apparent atomicity of the object.  A representation of a telephone makes
a much cleaner active object than a bunch of related resources cobbled
together as class MyImportantObject.

> yes. this code has legs!
> 
> cheers,
> scott
> 

Well, no, actually - as I discovered when trying to generalise it :)
I do have a better version, which I'll post when I'm happy with it.

Matt