[boost] Re: Future of threads (III)

From: Matthew Vogt (mvogt_at_[hidden])
Date: 2004-02-16 20:51:17

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.

> > It may be of some utility, especially if it can be reworked to allow 
> > for interface inheritance from the wrapped object.  If nothing else, 
> > it shows how lots of boost libraries can be combined in a short 
> > space of lines...
> 
> All I can say is wow and very impressive!  I believe you have managed to
> leverage the power of several boost libraries very nicely.  Anyway, I think
> the example is a bit contrived in that having the main thread block for a
> response, but still very cool.

Thank you.  Yes, it is very contrived, and fairly limited.  But, since I 
don't actually know why I might want to even use it myself, I wasn't really
concerned with improving the code too much.  It is a good feeling, though, 
to be typing in 'boost::' even more often than 'std::'... :)

> One of the interesting points of your example is that a cross-thread queue is
> needed.  Several people have mentioned this as a priority for the thread
> library and I agree.  Every multi-threaded app I've seen needs a cross-thread
> queue...

Absolutely.  I have never seen a multi-threaded app that didn't boil down 
to thread-safe queue access, although I'll admit that there are many classes
of app that I have never seen.
FWIW, Raoul Gough mentioned his 'safe_queue' (sp?) in the 'Future of threads
 (II)' thread, but it didn't seem to be ready for public display.

> > I'm sure it can stand a lot of refinement, but I can't be bothered 
> > working on it any more!  
> 
> Too bad, seems like you could make a nice contribution  

No, the fact is I can't grok how boost::function<> parses it arguments, and
a working sketch was good enough for me.  Now, if only I knew of a reason why 
I might want to actually *use* it...

Matt