-
Notifications
You must be signed in to change notification settings - Fork 53
what's the timeline? #5
Comments
When working on pepper.js, it became clear that the biggest stumbling block was threading and concurrency. For the past few months I've been trying to figure out threads in JS. That's been a lot of research and prototyping, but none of it shows up in the repo. There is love and attention here, but right now it's all forward looking "how the heck could this be standardized" sort of stuff. As for folding it into the SDK, I've been gating on "one major user". If pepper.js gets folded into the SDK, it adds another configuration for the SDK folks to deal with. To take that step, I need to show (to myself, if no one else) that this has legs. There's an internal product at Google that may fit the bill, but I've been focusing of the threading stuff to the exclusion of all else. Your prod has reminded me that I should be pursuing this, too. Thanks. I'll see what I can make happen in April. |
Excellent! I think developers (or, at least, myself) want to develop in Pepper without worrying about whether pnacl or asm.js will win. Probably the best that you can do is document a threading pattern based on unique_ptr or move semantics (something like Mozilla Rust). Secretly the data is copied to/from web workers behind the scenes. I'm not saying to write your own threading library, but rather to hack the data movement into the Boost/C++11 library behind the scenes. Then publish a pattern that declares that shared state and mutexes will be ignored and should not be used. Frankly, C++ needs a documented pattern like this anyway. I'd just follow the Rust model (they seem to have thought it through) |
+1 - I'm keeping an eye here waiting for news :) |
@ncbray Re: threading: You can use my Core Estimator to get an estimate of the number of CPU cores for browsers that don't support NaCl As for performance: It scales logarithmically with the number of cores, so your future 128-core workstation shouldn't take over 8-15 seconds or so to fully estimate (depending on the speed of the individual cores). I'm also looking into integrating the NaCl method so Chrome users don't have to run the timing attack. |
@sstirlin Speaking of Rust... (shameless self-promotion). Beware: it is a WIP and barely works as is. |
Update regarding core count: this value has been standardized as navigator.hardwareConcurrency and is shipping soon in WebKit and Blink. |
@DiamondLovesYou: NICE! Do you have any of the Pepper API ported yet? |
@sstirlin Parts of it!. Here's the (admittedly rather sparse) documentation. |
When I try to build the library rustc compiles and some of the libs Is that a known problem? any idea how to fix it? rust-nacl is a cool idea: On Wed, May 21, 2014 at 11:38 PM, Richard Diamond
|
pepper.js doesn't seem to be getting the love and attention that it deserves from the Native Client team (1 developer, no commits for 2 months).
This project needs to folded into the main Native Client SDK and polished. It needs to become part of the "standard way". A pnacl solution by itself is a tough sell. A pnacl + fallback to emscripten solution is far easier to justify
The text was updated successfully, but these errors were encountered: