Threading Problem with Nashorn

[Andrew Thompson]

On Jul 9, 2013, at 6:34 AM, Attila Szegedi <attila.szegedi at oracle.com> 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)