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)
