[mailto:boost-bounces@lists.boost.org]On Behalf Of Matthew Vogt
Ok. Well there is obviously some sort of networking infrastructure including a event dispatching as well. Again, these are items that are needed in boost, have had prior work (in the sandbox), but aren't ready for primetime yet.
This in particular seems to be a big stretch of scope. I think it would be brave to try to put network-transparent messaging into boost.threads, without first going through an inter-thread messaging stage.
Works for me. <snip>
Otherwise, Scott and I have been discussing interactions based purely on message passing between objects, utilising a separation between 'servant' and 'scheduler' that is reminiscent of the active object
Yep. And the following is pasted in from the other thread; thought I would try to pull it all together. Apologies for loss of indentation.
Anyway, I think some reasonably clean syntax can be found to bind both the arguments and the return address into the function call, provided that the return address is a method in the invoking object.
Well, after some fiddling, the best I can manage is: class SomeClass { public: std::string value(int id) { return "foo"; } } class ThatServant : public reactive<ThatServant>, private SomeClass { public: ThatServant() : getValue(&ThatServant::value, this) {} method<std::string (int)> getValue; }; class ThisServant : public reactive<ThisServant> { public: void findAndStoreValue(ThisServant& other, int id) { (return_to(&ThisServant::storeValue, this)) = other.getValue(int); } private: void storeValue(std::string value) { ... } } Got that. I have to leave it up to you. We seem to have worked through one major area of conceptualizing; schedulers and servants. These take a big whip to the business of taming threads. We are now at the point of deciding how these beasts will communicate amongst themselves. Is it to be "method-based" or "message-based"? I can see that your baby will sing but so does messaging. If we can agree on something here then we would have a complete target for something built on boost.thread, i.e. there are no other "areas"? Cheers, Scott