Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Taste of JavaScript's New Parallel Primitives

hacks.mozilla.org

Post reply on HN
Print view View original

91–100 of 107 posts

Re: A Taste of JavaScript's New Parallel Primitives

#91

Post by _yosefk »

AgentME wrote: post #86
_yosefk wrote: post #84

Earlier quoted context omitted.

I'm curious about 2 things: 1. How is the accidental modification of random JS objects from multiple threads prevented - that is, how is the communication restricted to explicitly shared memory? Is it done by using OS process underneath? 2. Exposing atomics greatly diminishes the effectiveness of automated race detection tools. Is there a specific rationale for not exposing an interface along the lines of Cilk instea…

1. You can't ever get a reference to regular objects that exist in other threads (workers). Communication with workers is limited to sending strings, copies of JSON objects, transfers of typed arrays, and references to SharedArrayBuffers. 2. I assume it was done at a low level so that multi-threaded C++ could be compiled to javascript (asm.js/WebAssembly).

For (1) does this mean that everything in the global namespace barfs when called from a worker thread?

(2) sounds like it might need a larger set of primitives, though I'm not sure.

Re: A Taste of JavaScript's New Parallel Primitives

#92

Post by warfangle »

schmichael wrote: post #47
warfangle wrote: post #44

Earlier quoted context omitted.

So, you're pretty negative on WebGL then?

Pretty meh. I'm sure there are some excellent uses of it that I encounter and enjoy without realizing it, but few of the advanced demos work for me (Chrome on Linux w/Intel gfx) or bring my computer to its knees rendering at very low FPS. It feels like something that was more interested in competing with native than offering a constrained and portable approach.

Quake 3 doesn't work for you? :)

http://media.tojicode.com/q3bsp/

Re: A Taste of JavaScript's New Parallel Primitives

#93

Post by bobajeff »

mindcrime wrote: post #68
dherman wrote: post #38

Earlier quoted context omitted.

I don't know if there's a uniform Mozilla position on this, but here's mine! :) The main reason I care about the Web is because it's the world's biggest software platform that isn't owned. If someone can deliver their app to the world without submitting it for review by an app store and without paying a company a %-age of the revenue, and if they can market it through the viral power of URLs, then they have a lot mor…

But more importantly, you just can't beat the URL. How many more times will we convince the entirety of humanity to know how to visually parse "www.zombo.com" on a billboard or in a text message? It's easy to take the Web for granted, it's fun to snark about its warts, and there's a cottage industry of premature declarations of its death. But I personally believe that the humble little hyperlink is at the heart of th…

That would require plugins which are being phased out and for good reason.

Namely, because they allow something like Adobe Flash Player - which doesn't come close to supporting all the platforms the Web runs on - to become a defacto standard. Thus restricting a large portion of the Web to just a few platforms Adobe wants to support.

Re: A Taste of JavaScript's New Parallel Primitives

#94

Post by mindcrime »

bobajeff wrote: post #93
mindcrime wrote: post #68

Earlier quoted context omitted.

But more importantly, you just can't beat the URL. How many more times will we convince the entirety of humanity to know how to visually parse "www.zombo.com" on a billboard or in a text message? It's easy to take the Web for granted, it's fun to snark about its warts, and there's a cottage industry of premature declarations of its death. But I personally believe that the humble little hyperlink is at the heart of th…

That would require plugins which are being phased out and for good reason. Namely, because they allow something like Adobe Flash Player - which doesn't come close to supporting all the platforms the Web runs on - to become a defacto standard. Thus restricting a large portion of the Web to just a few platforms Adobe wants to support.

That's one way of looking at it. OTOH, not allowing plugins arbitrarily restricts web users to the lowest common denominator of technologies that are supported by browser vendors. Why should I care to have my technology choices dictated by browser vendors any more than I care to have them dictated by Adobe?

That said, nothing about what I'm proposing specifically requires plugins. All it would require would be for the browser vendors to work together (cough, cough, I know, cough cough) to implement a standard mechanism for doing this. Actually, it might not even take that. Browsers already have a way to setup handlers for unsupported content types and what-not, so it might be possible to build what I'm thinking about largely on top of that. Of course it would mean that if you wanted to run an "application" UI you'd have to have a suitable platform (an X server, or something like an X server) running along-side your browser. So you maybe wouldn't be able to run OpenOffice on your smart-phone. OK, personally, I can live with that. Not all devices are equivalent and there's no reason to expect every thing to work one every device.

Re: A Taste of JavaScript's New Parallel Primitives

#95

Post by pcwalton »

schmichael wrote: post #41
dherman wrote: post #38

Earlier quoted context omitted.

I don't know if there's a uniform Mozilla position on this, but here's mine! :) The main reason I care about the Web is because it's the world's biggest software platform that isn't owned. If someone can deliver their app to the world without submitting it for review by an app store and without paying a company a %-age of the revenue, and if they can market it through the viral power of URLs, then they have a lot mor…

> without paying a company a %-age of the revenue It may not be a %-age of revenue, but you definitely can't host a non-trivial webapp for free either. You could even argue that in many webapps scaling costs are proportional to revenue, which makes it awfully similar to an app store. > But also I think there's a false dichotomy between "the Web should just be for documents" and "the Web should just be for apps." Yeah…

> Yeah, I don't have a clear idea on where the web should "end", but wow... web pages able to eat all my cores and have data races seems like a line to be crossed with great caution and care.

We crossed that line long ago (well, not precisely with data races, but with message/event ordering races...)

Re: A Taste of JavaScript's New Parallel Primitives

#96

Post by [deleted] »

schmichael wrote: post #30

> if we want JS applications on the web to continue to be viable alternatives to native applications on each platform This is where I disagree with the direction Mozilla has been going for years. I don't want the web to be a desktop app replacement with HTTP as the delivery mechanism. I'm fine with rich single page web apps, but I don't understand the reason why web apps need complete feature parity with desktop apps…

[deleted]

Re: A Taste of JavaScript's New Parallel Primitives

#97

Post by tnorthcutt »

Klathmon wrote: post #34
schmichael wrote: post #30

> if we want JS applications on the web to continue to be viable alternatives to native applications on each platform This is where I disagree with the direction Mozilla has been going for years. I don't want the web to be a desktop app replacement with HTTP as the delivery mechanism. I'm fine with rich single page web apps, but I don't understand the reason why web apps need complete feature parity with desktop apps…

For me, it's because "native apps" still fail at the first step, installation. Whether it's a website, or web-app, "installing" it is as easy as going to a URL. You can go to that same URL on your PC, phone, tablet, your friend's computer, etc. and it will run the same. It's easy to share, easy to remember, and if it takes more than 5 seconds from the time you hit enter to the time you are using it, we consider that…

Relevant: https://xkcd.com/1367/

Re: A Taste of JavaScript's New Parallel Primitives

#98

Post by bobajeff »

mindcrime wrote: post #94
bobajeff wrote: post #93

Earlier quoted context omitted.

That would require plugins which are being phased out and for good reason. Namely, because they allow something like Adobe Flash Player - which doesn't come close to supporting all the platforms the Web runs on - to become a defacto standard. Thus restricting a large portion of the Web to just a few platforms Adobe wants to support.

That's one way of looking at it. OTOH, not allowing plugins arbitrarily restricts web users to the lowest common denominator of technologies that are supported by browser vendors. Why should I care to have my technology choices dictated by browser vendors any more than I care to have them dictated by Adobe? That said, nothing about what I'm proposing specifically requires plugins. All it would require would be for th…

That's true you don't actually need a browser to do what you're talking about. In fact I'm pretty sure x11 already does this.

Re: A Taste of JavaScript's New Parallel Primitives

#99

Post by AgentME »

_yosefk wrote: post #91
AgentME wrote: post #86

Earlier quoted context omitted.

1. You can't ever get a reference to regular objects that exist in other threads (workers). Communication with workers is limited to sending strings, copies of JSON objects, transfers of typed arrays, and references to SharedArrayBuffers. 2. I assume it was done at a low level so that multi-threaded C++ could be compiled to javascript (asm.js/WebAssembly).

For (1) does this mean that everything in the global namespace barfs when called from a worker thread? (2) sounds like it might need a larger set of primitives, though I'm not sure.

1. Web workers don't share a javascript namespace or anything with the parent page. They're like a brand new page (that happens to not have a DOM). Outside of SharedArrayBuffer, there's no shared memory.

Re: A Taste of JavaScript's New Parallel Primitives

#100

Post by brazzledazzle »

slavik81 wrote: post #62
CiPHPerCoder wrote: post #59

Earlier quoted context omitted.

I use quotes differently than journalists. I use them to indicate "this is a separate sentence that expresses an idea mid-sentence" and to indicate tone shift, not as a quote for a specific person. I use a > prefix for direct quotes. That exact string isn't from the Github issue, it's a summary of one argument dismissing some of the OpenSSL RNG's worst issues. Here are two direct quotes if that's what you want: > for…

Forking and threading are different things. Forking creates new processes and duplicates memory. It raises entirely different issues from multi-threading, which does neither. See: http://stackoverflow.com/q/2483041/331041 They discussed forking, but did not discuss multi-threading.

So for OpenSSL's RNG vs. the operating system's CSPRNG is there a difference between forking and multi-threading?
Post reply on HN