Okay, thanks for the notification. I'll close the bug for now -- we can
re-open if there is any nashorn issue identified during the work you do
on handlebars.
Thanks,
-Sundar
On Monday 01 June 2015 05:35 PM, Sebastien Deleuze wrote:
See Handlebars developers feedback [1].
As suggested before, Handlerbars is not designed with concurrency in mind,
but they may accept some pull requests to improve that if that means no
regression for other regular users.
I will try to have a look to at least identify what should be done and have
an idea of the amount of work needed to fix that.
[1]
https://github.com/wycats/handlebars.js/issues/1031#issuecomment-107271075
On Tue, May 26, 2015 at 7:50 AM, A. Sundararajan <
[email protected]> wrote:
Oops. double negative :)
/but the compiled handlebars function may not be MT-unsafe./
should have been
"but the compiled handlebars function may not be MT-safe".
-Sundar
On Tuesday 26 May 2015 11:15 AM, A. Sundararajan wrote:
Actually either the Handlebars.compile or the compiled function could be
MT-unsafe. FWIW, I tried the following change to handlebars's render.js
script:
function renderHandlebars(template, model) {
// Create a real Javascript Object from the model Map
var data = {};
for (var k in model) {
// Convert Java Iterable and List to real Javascript arrays
if (model[k] instanceof Java.type("java.lang.Iterable")) {
data[k] = Java.from(model[k]);
} else {
data[k] = model[k];
}
}
// TODO Manage compiled template cache
var compiledTemplate = Handlebars.compile(template);
// call compiled template function as synchronized
// use Handlebars object as lock
return Java.synchronized(function(data) {
compiledTemplate(data);
}, Handlebars);
}
With that change, it appears handlebars MT-usage seems fine [i.e., no
exception seen]. This suggests that the Handlebars.compile itself is
MT-safe but the compiled handlebars function may not be MT-unsafe. FYI.
