Threading Problem with Nashorn

[Attila Szegedi]

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 <lordpixel+openjdk at mac.com> wrote:

> 
> 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)
>