Can I start working on ConcurrentExecutionsTest ?
I can see all unit tests are successfull... Only SequenceTest has problems probably due to lock problem...
Have you this test running on your side ?
If yes, can you post the code in the forum ?
Thanks a lot
the returnvalue in the nodebehaviour methods turned out to be a dead end. the reason is that there were way too many returnvalues. so that is why i went back to method invocation for execution propagation. the 'proceed' method makes it possible to write nodes that can be used in transition based execution and block structured execution.
This is much more natural for us than using NodeState returns. I've also like new features such end, start methods, execution scopes stack as well as execution states. Those concepts were manually handled before in each language extension so I think its great to have them in the PVM.
I've just updated the CurrentIncomingTransitionTest to add execution status update and check.
I was now working into more tricky Fork and Join scenarios (Nested forks ending in the same Join). I didn't found yet a way to do that by leveraging ExecutionScopes... I will continue on that.
i'm pretty happy with what we've got so far as well.
but there is only one concern left:
* a node is executed inside an atomic operation.
* each execution has got its own queue of atomic operations
* node behaviour can create and operate on another execution. this currently causes the other execution to start a new while loop to perform those other execution's atomic operations
* so what if that execution in that while loop signals back to the first execution ? that one is still in the middle of an atomic operation... i couldn't figure out why that worked :-)
but now, explaining it worked therapeutically. yes! now i understand that when a child execution performs another operation back on the parent execution, the operation will just go at the end of the atomic operations queue.
so the only thing that is left is that you're not sure of the state of your parent execution in the child execution. therefor, you still must make sure that you update the parent execution's state first, and only after that interact with the child execution.
i'm not explaining it very proper... but it was a great relief. thanks :)