scott <scottw <at> qbik.com> writes:
What is lacking is the ability to multiplex over events relating to the delivery of future values. You can't use select, poll or WFMO to determine whether any of an outstanding set of futures have been delivered. I think that this probably makes active objects an inappropriate choice for designs that are inherently reactive.
Yes, exactly. Is there no potential to leverage the mechanism you already have, i.e. "task"?
Yes, you can (if I now understand what you're asking correctly) - in the parlance of the code we've been discussing, you can achieve this by having all objects 'active' (with a thread), and having all functions as void functions that produce flow-on effects to other objects. Essentially, I send a message from my object to another object, and I receive the result not as a return value, but as a new message from the other object. But, as you point out later, we've now changed patterns. The limitation resulting from the unequal status of different event mechanisms is a fairly fundamental one. Is anyone working on this in a boost threads context?
It seems almost tragic that you have such a slick method of delivering "Method Requests" and that it cant be used to deliver "Method Results" asynchronously.
There isn't any intention to have a slick method of result propagation; the intention is to allow code which is not specialised for multi-threading to seamlessly invoke code which will be performed in another thread. Although I understand what you're looking for.
In another implementation this just involved storing some kind of "return address" and adding that to the queued object (task). On actual execution the thread (belonging to the active object) need only turn around and write the results back into the callers queue.
This implementation requires that all objects have a queue, which is another property of the 'reactive object' system you're describing, but can't work with the approach I've taken.
The ActiveObject pattern was introduced early on and became a convenient vocabulary and point of reference. In truth it was never my target (I hadnt seen it previous to our discussion). It is totally impressive work but does duck a major nasty.
So, to hopefully clarify; I still feel there is a software abstraction that we (as developers) intuitively want. It is not completely delivered by the ActiveObject pattern (though I thank JG again for the reference).
<snip>
When I refer to asyn-res I am typically referring to the delivery of results from one active object to another, where the receiving object is not required to enter into a (potentially) blocking call (e.g. evaluation of a future). I have tried to label this circumstance as "symmetric activation". This can only occur between two active objects <cringe>.
Ok. Having established that this is a different pattern of multithreading, what are the costs/benefits of symmetric activation?
What interface are you using to allow active objects to access results generated by other active objects?
The short answer is; the same interface used to deliver Method Requests. The long answer would definitely be long. I can post some code fragments if we are still swimming after the same stick?
Right; so all objects (even non-threaded ones) contain a task queue? (Or, perhaps 'interaction queue'?) When a request is queued to a non-threaded object, how does that request get processed?
Its been fun up to this point but perhaps your "code with legs" is viable as "active object" and that is a valid first phase? I could wheel my barrow off to the side for a while
Cheers, Scott
Yes, I don't think my code can be modified to incorporate your requirements. I am interested in your pattern, though. Perhaps a change of subject is in order? Matt