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 < sundararajan.athijegannat...@oracle.com> 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. >> > >
