Provide way for making template compilation thread-safe

[jfrantzius]

While compiled templates are thread-safe during rendering, it seems that template compilation itself is not.
When we run compilation concurrently for the same template, we are suddenly seeing errors during parsing like this:

:1659:13 Error: Parse error on line 21:
...         {{/content}}{{/extend}}
------------------^
Expecting 'EOF', got 'OPEN_ENDBLOCK'
    at jdk.nashorn.internal.objects.NativeError.initException(NativeError.java:137)
    at jdk.nashorn.internal.objects.NativeError.(NativeError.java:102)
    at jdk.nashorn.internal.objects.NativeError.(NativeError.java:106)
    at jdk.nashorn.internal.objects.NativeError.(NativeError.java:110)
    at jdk.nashorn.internal.objects.NativeError.constructor(NativeError.java:129)
    at jdk.nashorn.internal.scripts.Script$Recompilation$5799$67279AA$\^eval\_.L:36$L:1391$handlebars$parseError(:1659)
    at jdk.nashorn.internal.scripts.Script$Recompilation$4599$67366A$\^eval\_.L:36$L:1391$handlebars$parse(:1728)
    at jdk.nashorn.internal.scripts.Script$Recompilation$4596$37999AA$\^eval\_.L:36$L:1342$parse(:1386)
    at jdk.nashorn.internal.scripts.Script$Recompilation$4595$119328$\^eval\_.L:36$L:2733$compile-1$compileInput(:3247)
    at jdk.nashorn.internal.scripts.Script$Recompilation$4594$119696AA$\^eval\_.L:36$L:2733$compile-1$ret(:3256)
[..]

This error disappears when we isolate Handlebars instances in our threads, i.e. if we prevent concurrent template compilation on the same Handlebars instance. This comes with a performance penalty that is hard to workaround, though.

Possibly there is some parsing state global to the Handlebars instance or in the Jison generated code?

[nknapp]

JavaScript is single-threaded and thus there is no concept for synchronization of multiple threads. I'm not sure if the single-threadedness is part of the spec, but I would assume so (NodeJS is and Browsers are two).
The only ways to provide a little multi-threading are asynchronous callbacks, Promises and events, and as far as I know, none of those are used in Handlebars.

Nashorn should not allow multiple threads to access variables of the same Handlebars-instance at the same time. A piece of JavaScript-code always expects to run to the end before other code can modify its variables.

Edit: Corrected last paragraph.

[nknapp]

I just noticed that you are using the extend-helper. The problem seems to be similar #1031

[jfrantzius]

Hi @nknapp the extend-helper is the reason why some templates get re-compiled over and over. This wouldn't be a problem for us (except for a bit of a performance loss) if Handlebars compilation was thread-safe.

We now workarounded the problem by funneling all compileInput() calls through a Java method that takes care of thread synchronization, i.e. it serializes executions. This works with a little patch to handlebars-v4.0.5.js.

[nknapp]

What is the patch to 4.0.5 that you are using? Maybe this can be included in the release.

[jfrantzius]

We're currently calling a custom Java class method of our own that is synchronized. But something similar should be possible using the Nashorn extension Java.synchronized(function, lock). You'd have to add some if (typeof Nashorn !== 'undefined') that tests for presence of Nashorn extensions, though, as that of course doesn't work outside of Nashorn.

But unfortunately I discovered that there are more multi-threading issues at rendering time (i.e. even after template compilation), likely caused by use of closures in handlebars-4.0.5.js. From what I understand at the moment, closures will always cause multhreading-issues, at least as of current Nashorn logic.

[stevenvachon]

The DOM has Worker for pseudo-multi-threading, while Node.js has cluster. webworker-threads is a nice isomorphic interface.

[nknapp]

Closing due to inactivity.