From: Matthew Vogt (mvogt_at_[hidden])
Date: 2004-02-23 22:13:47
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
> 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
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).
> 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
> 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
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk