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