On Fri, May 9, 2008 at 8:46 PM, Tomaso Tosolini <[EMAIL PROTECTED]> wrote: > > ok for the previous considerations I understand and agree with you. And also > I'm sure that the current is the first implementation so you will add much > more features in the near future....
Hello Tomaso, I will try to limit the features added to "step" as I'm currently not sure if it's a good idea for people to use it for everything. People should use sequence for sequences and not try to do everything with "step". Else they should work with a state/transition oriented workflow engine. (Maybe I'm wrong and I'll painfully change my mind later :) ) > When in step process the participant replies, following subprocess is > invoked by the engine with an apply method call and this starts the new > subprocess, i.e. we are going down in the execution tree( please correct me > if I'm wrong, because I'm not sure that the concept of execution tree may be > applied here... ). > Now being within another step when calling the next subprocess/step we still > move down into the execution tree. > Now this is is not completely clear to me but it seems that we continue > going down in the exec tree until the "final_step(s)" where we get out of > all the nestings, in a rather similary way to what happens in recursive > functions. > What I was asking myself was: suppose you have a control process, which runs > forever without exiting ( continuos monitoring processes may have such > requirement ), if we continue indefinitely to walk the tree in the down > direction don't we risk to create very deep execution trees, and having > "stack" problems? Indeed if I'm not completely wrong is it possible to > experience slowings expecially on functions that work on feis since they > tend to become (very) long strings of dot separated integers. You're right, I added some debug output to the ExpressionPool and I noticed that I did something wrong is the launch_subprocess() code. A tree can grow like : ---8<--- [:apply, "20080510-gegunotsude", "0", "process-definition"] ... [:apply, "20080510-gegunotsude.0", "0.4.0.1", "out:dev_fixed"] [:apply, "20080510-gegunotsude.0.1", "0.9", "process-definition"] [:apply, "20080510-gegunotsude.0.1", "0.9.0", "step"] [:apply, "20080510-gegunotsude.0.1", "0.9.0.0", "qa"] [:reply, "20080510-gegunotsude.0.1", "0.9.0.0", "qa"] [:reply, "20080510-gegunotsude.0.1", "0.9.0", "step"] [:apply, "20080510-gegunotsude.0.1", "0.9.0.1", "out:qa_fixed"] [:apply, "20080510-gegunotsude.0.1.2", "0.7", "process-definition"] [:apply, "20080510-gegunotsude.0.1.2", "0.7.0", "finalsteps"] [:apply, "20080510-gegunotsude.0.1.2.3", "0.11", "process-definition"] [:apply, "20080510-gegunotsude.0.1.2.3", "0.11.0", "concurrence"] [:apply, "20080510-gegunotsude.0.1.2.3", "0.11.0.0", "cs"] [:apply, "20080510-gegunotsude.0.1.2.3", "0.11.0.1", "qa"] ... --->8--- should grow to be 20080510-gegunotsude.3 and not 20080510-gegunotsude.0.1.2.3 As you can see, there is something wrong with this .0.1.2.3 and that totally validates your "longer and longer feis" hypothesis. Fortunately it won't be too hard to fix ( http://rubyforge.org/tracker/index.php?func=detail&aid=20059&group_id=2609&atid=10023 ) > My idea about the state-transition working mode was to build things such > that the "goto" expressions, insead of transferring the control to the next > state using the apply method, call the state-transition's reply method and > then the dispatch to the next state was performed by the state-transition > calling the appy method of the designed next state, but in this case we are > doing this at the state-transition context, now within the current state's > context. The context for the transition is the one the "step" expression is, the "state" itself (in case it's a subprocess) has it's own context. > My idea was that such working mecha should keep the exec tree quite > flat, or if not, at least his deepness is due only to the process definition > schema, not to the workitem process execution "real path". It would be a good exercise to implement your suggestions (maybe a fork of Ruote). One technique to avoid such fat stacks would be to use "tail recursion" ( http://en.wikipedia.org/wiki/Tail_recursion ), it's not implemented in Ruote to keep things simple (and it's not implemented in Ruby itself neither (though I don't know for 1.9 / yarv)). Maybe you can sketch an implementation of your idea or write down how you see the stack (the expool) would grow. It could help me understanding your idea. > I'm not completely sure than my considerations track an existing problem or > instead the Ruote internal working mode already prevents this issue, so I > ask as usual... It's an excellent question (calls for a long answer :) ) Cheers, -- John Mettraux - http://jmettraux.wordpress.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OpenWFEru dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/openwferu-dev?hl=en -~----------~----~----~----~------~----~------~--~---
