I believe that's a reasonable approach. The JavaScript "Global" object is actually ENGINE_SCOPE level state, so you should be fine.
Attila. On Jul 13, 2013, at 4:51 PM, Andrew Thompson <[email protected]> wrote: > > On Jul 9, 2013, at 6:34 AM, Attila Szegedi <[email protected]> wrote: > >> Actually, in your above example, since the JavaScript program has no >> explicit guarding of concurrent access to variable `i` you seem like you >> would actually even expect to have an engine that has "THREAD-ISOLATED" as >> its threading model instead of the simpler "MULTITHREADED" - that' very rare >> in an engine, usually hard to implement efficiently (do you clone all of the >> data up front? do you implement a copy-on-write semantics?) , and is >> functionally simpler to just have a non-threadsafe engine and let the users >> manage their own thread isolation by creating one engine instance per thread. > > > In a model like that, what' s the best way to manage state? > > Assuming I want to make sure each invocation of eval() is unable to influence > the next invocation - i.e. leave no ENGINE_SCOPE or GLOBAL_SCOPE behind > between calls to eval, would it looks something like this: > > ThreadLocal<ScriptEngine> engine = ... > > ScriptContext sc = new SimpleScriptContext(); > > engine.get().eval(someScript, sc); > > Is that a reasonable approach to getting isolation between eval() calls or is > it overkill? Would creating new bindings be a better idea? This leaves > leakage through GLOBAL_SCOPE but is GLOBAL_SCOPE visible to the JavaScript > code? > > ScriptEngine e = engine.get(); > Bindings b = e.createBindings(); > e.eval(someScript, b); > > I am very interested in contrasting this with the worker model Jim Laskey > posted about in the next message in this thread. > > > AndyT (lordpixel - the cat who walks through walls) > A little bigger on the inside > > (see you later space cowboy, you can't take the sky from me) >
