I have no idea why Mozilla was so resistant to pnacl. It's a nice step beyond the nasty legacy JavaScript mess. Among other things, JavaScript is necessarily single threaded... Yea.
DRY? I think NaCl will require Mozilla to implement another VM or parser, and do same optimization it already does on JS. So why should they repeat themselves?
"WebWorkers are not really a multithread model. Game engines could be written to leverage message passing based isolates, but in some cases, but doing it in an optimal form isn't exactly developer friendly, it's one of pains of developing the PS3 SPEs is that they didn't share system memory and you had to DMA stuff around."
Anyway, he said that the problem with Pepper is that its API is gigantic and its only spec is the implementation in Chromium. Other browsers could port the API but it come at very high cost due to WebKit-specific glue code.
The "problem" with pnacl is that it means the end of Javascript's death grip on the browser, which Brendan Eich is interested in extending for obvious reasons
To be clear, there are two things that have historically been called "pepper". The first was a basically a better version of NPAPI, with the limited scope that implies. That was replaced by something that's basically a Google-proprietary replacement for the entire web stack, with both the scope and the problems that implies.
It may run on multiple threads but I don't think it exposes threading to the runtime. Ecmascript is certainly single threaded and async by design, so v8 would be straying far from the spec.
for opening up a new separate thread, that you can only communicate through message passing. It's not part of the core language but the browser library hence why you can't use them in Node.
They're also more directly comparable to processes than threads, as they do not share memory (though there are a couple of proposals to allow them to).
