Closed Taritsyn closed 5 years ago
I think I found the reason. For the Literal AST node we cache the .NET value in the JintLiteralExpression one of Jint. But for the CallExpression (JintCallExpression) we rely on the AST to hold the value. And if you look at the JintCallExpression class you'll see it's not thread-safe in this case. This is the issue I think.
Would you be able to change this class locally to either store the cached value in the Jint expression itself, or to add some locking on the node when caching is done?
Created https://github.com/sebastienros/jint/pull/668 to address this issue, going to do separate PR for Esprima to remove the state from there.
Thanks!
Hello!
In my project I use the pre-compilation of scripts to improve performance. When I used the Jint version 2.11.58, I could easily initialize several engines by one parsed script. To make it clear to you how this works, I will give a slightly artificial example:
But after updating the Jint to version 3.0.0 Beta 1598 (also tested on version 14033f2), a similar example began to return unpredictable results:
The first call always returns the correct result, and results of remaining three calls, that are made in parallel, are completely unpredictable. Most likely, this is due to the fact that the engine is now changing the state of instance of
Esprima.Ast.Program
class during execution. I was able to temporarily solve this problem by deep copying of parsed scripts (I use the extension method from the .NET Object Deep Copy project).But to solve this problem, need more suitable solution, which will allow maintaining high performance. There are two variants:
ICloneable
interface in theEsprima.Ast.Program
class to make deep copy of the instance in most optimal way.