---- Reported by werner@yellowcouch.org 2007-11-20 11:15:10 ---- This can be done with the previously developed actor class. The arguments can be evaluated concurrently. When all the arguments came in the thread can continue. Possible approaches: - ask the central store to calculate something - that one resopnse with the cached answer - or with a busy response - if busy we wait until we receive an answer from some other actor - each calculation is linked to a colelction of listeners that are interested in the answer This approach requires that an actor can receive fillins for specific values up in its execution stack. If the top of the stack lacks a certain value then it must go in wait until that value is retrieved. In our case this means that we have a function stack which describes the state of the argument evaluation. The problem here is that we need a way to put the current execution stack completely on hold. Setjmp and longjmp like solutions might work but its probably easier to simply go into a wait loop A second approach is to have target placeholders that keep track of the resultstate in a slightly different manner. Instead of executions something we ask it to be executed with a futureresultplace. That place holds 'busy', 'calculating' and a method to wait for the answer. When something is being calculated the result is automaticallky posted to the right thread. So we need a central worker that will keep track - a central worker that keeps track of all the calculation requests - a futureplace that can wait until a result returns. In the argument evaluator we simply run through all the arguments to be evaluated and queue those that we will need to evaluate. So maybe we should work with an explicit stack ? in which we have a queue and a stack. The queue is that what we will need, the stack is that what we are currently busy with. Anyway, I dont want to give up the C++ stack, I rather figure out a way how to queue evaluations. A good thing would probably be to be able to specify where the result should be and as soon as we look up the result and there is none available we can start waiting. ResultPlace -> to retrieve the value we simply need to wait until the value is there. So in a sense we can background the evaluation when we think it is useful (being not cached). A good question is how a thread that is waiting can postpone its own execution. This can be done in the resultplace which if it goes into wait must store the current execution stack somehow. When a message comes in, this execution stack must be restored. --- Bug imported by werner@yellowcouch.org 2008-12-26 11:56 --- This bug was previously known as _bug_ 173 at http://werner.yellowcouch.org/borgflowbugs/0