On Dec 1, 12:06 pm, Attila Szegedi <[EMAIL PROTECTED]> wrote: > It makes perfect sense. If you want to multiplex a bunch of > simultaneously running scripts on a handful of Java threads, > continuations are the way to go. > > Attila. > > -- > home:http://www.szegedi.org > twitter:http://twitter.com/szegedi > weblog:http://constc.blogspot.com > > On 2008.12.01., at 17:54, David Parks wrote: > > > I tried playing with observeInstructionCount, but since I can't > > imitate a > > continuation from there, there is no way for me to return control > > back to a > > worker thread. I am trying to execute a large number of scripts > > simultaneously and continuously, but each script needs only a very > > small and > > measured amount of CPU time (as a simplified example consider, 1000 > > instructions allowed per second per script max). > > > Unless I am missing something obvious (and don't put missing the > > obvious > > past me, I am plenty capable of that) :), then I would need to fully > > instantiate 10k threads if I have 10k scripts running. This is > > because there > > is no clean way of saving _and resuming_ the state of the script > > execution > > at the call to observeInstructionCount (the example usage for that > > method > > only breaks execution, but does not allow it to resume). So I can't > > see a > > way to use an efficient threadpool to iterate through all 10k scripts > > allowing them to execute only their allotted timeslice without > > continuations > > either at the JS level or the thread level. > > > But your comment makes me a little nervous that I did miss something > > obvious, is there something you see here, or does this situation > > make sense? > > I heard from one other person when I originally posted the question > > related > > to this post that he was interested in similar functionality. > > > Thanks! > > Dave > > > -----Original Message----- > > From: > > [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > a.org] On Behalf Of Norris Boyd > > Sent: Monday, December 01, 2008 3:24 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Info: A way to break script execution from outside the JS > > environment > > > On Nov 29, 11:12 am, "David Parks" <[EMAIL PROTECTED]> wrote: > >> Well, at least one person asked me to post or blog something if I > >> found a > >> way to limit how much processing any given script is allowed. > > >> So I'm posing this to provide one such solution (it's a hack, but > >> it works > >> well for my particular need). Perhaps the info will be useful to > >> others as > >> well. > > >> The solution/workaround for those interested: > > >> ---------------------------------------------------------- > > >> Based on the upcoming Rhino version 1.7R2 (release candidate 1 is > > currently > >> available, a link is in this forums archives), there are some new > >> features > >> around the continuation capabilities that allow you to capture and > >> resume > > a > >> continuation outside the JS environment. The limitation is that the > >> continuation must be initiated from within a JS function (it can be a > > Native > >> Java Method as in the provided test example ContinuationsApiTest > >> class). > > >> So the trick I've come up with (mind you, I'm quite sure that there > >> are > >> cleaner ways to implement this, I just don't know them nor want to > >> make > > the > >> numerous changes to the base code that would be required) is to > >> inject a > >> call to a JS function that will initiate the continuation. > > >> I've done this with some code in the interpreter that watches for > >> line > >> breaks (those appear to be safe places to inject a function call) > >> and also > >> watches for a Boolean condition to be set (in my case I'm counting > >> instructions and breaking when the # of instructions executed > >> exceeds a > >> threshold). At that point, instead of continuing execution of the > >> compiled > >> bytecode, I inject 5 operations, and allow them to process in > >> sequence > > (the > >> same 5 operations that would be used to make a JS function call), > >> then > >> restore the registers I used to their original state at the end. > > >> I've included the source that I changed Interpreter.class. It's set > >> up to > >> call the same object/function used in the ContinuationsApiTest class. > > There > >> are only 2 areas in the code that I updated, you can identify them by > >> searching for the word "hack" added in comments anywhere I made > >> changes. > > The > >> first is the code in the interpretLoop to inject the function when > >> appropriate, and the other is in the compiler to force it to > >> include line > >> changes even if the script doesn't have any newline characters > >> (this is > > just > >> to avoid a script stripping all newlines in an attempt to bypass this > >> mechanism, and will have the side effect of calling the onLineChange > > method > >> in the debugger multiple times for the same source line in some > >> cases). > > >> As part of my particular case I am executing many different > >> scripts, each > > in > >> their own scope, and each time I resume a particular scope/script I > >> have a > >> debugger object and contextData object associated with that scope. > >> I set > > the > >> debugger and contextData object that I've associated with that > >> scope each > >> time I resume processing a new script > >> (Context.SetDebugger(myDebugger, > >> myContextDataObj)). The Context Data object that is passed in > >> contains the > >> variables used by the workaround code in the interpertLoop, so it's > >> important to make sure that the contextData object stays with the > > particular > >> scope. > > >> As far as performance, I've been able to call a bit over 2000 > >> scripts, > > have > >> each of them performing a resume and suspend operation after > >> executing > > their > >> allotment of ~1000 bytecode operations, then perform a few other > >> minor > >> operations, all in 1 second on average using a laptops 1.9 ghz > >> single cpu > >> core processor. I am pretty happy with the scalability of JS > > continuations. > > >> Anyway, if someone tries this out I'd be happy to explain in more > >> detail. > > If > >> you want to play with this you should start with the included > >> ContinuationsApiTest.class and tweak that example with this little > >> hack in > >> place to see it working. > > >> Dave > > >> p.s. A big thanks to everyone contributing to Rhino!! And for > >> adding the > > new > >> continuation functionality, that was a homerun for me! > > > I don't understand why you need to use continuations for this. What > > are you trying to achieve that just using observeInstructionCount > > alone was insufficient for?
Ah, I didn't understand that you wanted to pause and resume the scripts. Continuations do make sense for that. --N _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
