scott <scottw <at> qbik.com> writes:
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.
Method-based can be layered above messages, if the messages support the concept of having their dispatch addresses potentially pre-bound. The scheduler of the message-driven system can do something like: message m = dequeue(); if (m.dispatch_bound()) { m.dispatch(); } else { servant->dispatch(m); } where the unbound case calls a function that switches based on the message code or content. Then all the proxies need to do to yield a method-based interface is bind the address into the message before queueing.
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"?
I think messaging between thread contexts is a useful target.
Cheers, Scott
Matt