Skip to content
This repository has been archived by the owner on Jul 27, 2022. It is now read-only.

what's the timeline? #5

Open
sstirlin opened this issue Mar 14, 2014 · 9 comments
Open

what's the timeline? #5

sstirlin opened this issue Mar 14, 2014 · 9 comments

Comments

@sstirlin
Copy link

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

@ncbray
Copy link
Contributor

ncbray commented Mar 14, 2014

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.

@sstirlin
Copy link
Author

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)

@fungos
Copy link

fungos commented Mar 16, 2014

+1 - I'm keeping an eye here waiting for news :)

@eligrey
Copy link

eligrey commented Apr 30, 2014

@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 sysconf(_SC_NPROCESSORS_ONLN).

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.

@DiamondLovesYou
Copy link

@sstirlin Speaking of Rust... (shameless self-promotion). Beware: it is a WIP and barely works as is.

@eligrey
Copy link

eligrey commented May 20, 2014

Update regarding core count: this value has been standardized as navigator.hardwareConcurrency and is shipping soon in WebKit and Blink.

@sstirlin
Copy link
Author

@DiamondLovesYou: NICE! Do you have any of the Pepper API ported yet?

@DiamondLovesYou
Copy link

@sstirlin Parts of it!. Here's the (admittedly rather sparse) documentation.

@danielrh
Copy link
Contributor

When I try to build the library rustc compiles and some of the libs
compile, but eventually
/home/daniel/Downloads/pnacl-rust/bin/rustc -C
cross-path=/home/daniel/Downloads/nacl_sdk/nacl_sdk/pepper_canary -C
nacl-flavor=pnacl --target=le32-unknown-nacl -L
/home/daniel/dev/rust-ppapi/deps/rust-http
--sysroot=/home/daniel/Downloads/pnacl-rust --cfg ndebug -O --cfg ndebug
--dep-info build/openssl.d --out-dir build lib.rs
lib.rs:1:1: 1:1 error: can't find crate for std
lib.rs:1 #![feature(struct_variant, macro_rules)]
^
error: aborting due to previous error
make[1]: *** [build/libopenssl-06cd96fd-0.0.so] Error 101
make[1]: Leaving directory `/home/daniel/dev/rust-ppapi/deps/rust-openssl'
make: *** [deps/openssl.stamp] Error 2

Is that a known problem? any idea how to fix it? rust-nacl is a cool idea:
I wonder if it could be made to work with pepper.js and emscripten as well!

On Wed, May 21, 2014 at 11:38 PM, Richard Diamond
notifications@github.comwrote:

@sstirlin https://github.com/sstirlin Parts of it!https://github.com/DiamondLovesYou/rust-ppapi.
Here's http://diamondlovesyou.github.io/rust-ppapi/ppapi/index.html the
(admittedly rather sparse) documentation.


Reply to this email directly or view it on GitHubhttps://github.com//issues/5#issuecomment-43853310
.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants