+1 for providing good summary in the beginning. I wish more articles had these.
JavaScript in Parallel: Web Workers and SharedArrayBuffer
61–70 of 74 posts
Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer
#62It is really how disappointing the options to share data with workers are in the browser. Combine the limited options options to transfer data quickly, and the limited API available in the worker itself (no version of a DOM, even a gutted one for doing measurements), it is no surprise how few opportunities to use them effectively there are. When it comes to transferring objects, it is so bad people are resorting to J…
I used web workers extensively in a JS project a little over a year ago, and it was a nightmare. Granted what I was attempting was crazy, but it shouldn't have been as painful as it was. Basically the "gotchas" are in the browser implementations. Each browser's web worker implementation is a little different, and those little differences (bugs) have huge implications in terms of what you can and can't do. For example…
Ios has a ui thread and a separate thread for application logic. React native makes good use of this to make applications silky smooth.
In Web land, the overhead of communication with workers is costly that it makes sense to do things in main thread. Preact had an worker diffing implementation but that was slower.
We once had to unzip on worker and pass to main thread, it was faster just to do it on UI thread.
Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer
#63I'd just like some high level guidance on how my browser makes use of threads internally. I feel like I could have further optimized a couple web apps with that knowledge.
Excluding web workers, just one thread per tab/window. So there's really no consideration for optimization via. parallelism unless you use web workers. And if I'm wrong, this is the quickest way to get the right info. :)
I'm pretty sure you're wrong. At the bare minimum, setTimeout must use a clock in another thread, since it doesn't block your primary thread code. I'm fairly sure that most of all of the JavaScript APIs that use callbacks are using additional threads, including the ubiquitous XMLHttpRequest.
Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer
#64What do people actually use Web Workers for? The examples I've seen, including this one, seem contrived. I keep hoping they'll change it to allow background image manipulation, but I haven't seen much real progress in that front.
We are experimenting with webworkers to power a very complicated autocomplete and scoring system in our client. So far so good. We're able to keep the UI running at 60fps while we match, score and sort results in a web-worker.
Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer
#65What are the statuses of Web Worker support in the mobile browsers? Android? iOS?
All browsers (except Opera Mini) support it: http://caniuse.com/#feat=webworkers
Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer
#66Earlier quoted context omitted.
Ah so you mean call other js processes through async/yield type stuff. I think that is cognitively easier than introducing new concepts like this has with a familiar way to do things. I agree with you. There would have to be some other syntax like "thread" to note it is not in the main thread but acted just like async or something. var somevalue = async doSomething(); var someExpensiveVAlue = thread doExpensiveThing(…
This is how it works in dotnet. var val = await Task.Run(() => doSomeThreadedWork(param)); Indicates to the runtime that the specified delegate may be run on another thread. This doesn't explicitly start a new thread but rather just allows the delegate to execute on one of the thread pool threads that is managed by the runtime. It uses heuristics to decide how many threadpool threads to maintain and whether to actual…
The issue is that in .Net there are locking primatives to access shared values... where as in Node/JS you would need something that only allowed passing of strings, other primatives, and SharedArrayBuffer or similar objects that don't change underneath unexpectedly.
Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer
#67Earlier quoted context omitted.
Excluding web workers, just one thread per tab/window. So there's really no consideration for optimization via. parallelism unless you use web workers. And if I'm wrong, this is the quickest way to get the right info. :)
I'm pretty sure you're wrong. At the bare minimum, setTimeout must use a clock in another thread, since it doesn't block your primary thread code. I'm fairly sure that most of all of the JavaScript APIs that use callbacks are using additional threads, including the ubiquitous XMLHttpRequest.
I'm not sure how the inner plumbing works. But since the queue just pops onto the stack, there's no true parallelism and therefore no optimization opportunity.
That being said, I'm not sure you're correct. There is no concern of blocking the main thread, since functions queued up via. `setTimeout()` are not tracked by some non-blocking timer. The queue is only inspected if the stack is empty. So if anything is happening, we just ignore the queue until nothing is happening. `setTimeout()` only guarantees a message will be processed after x milliseconds, not on-time.
https://developer.mozilla.org/en/docs/Web/JavaScript/EventLo...
Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer
#68Workers are really bad. Its anecdotal but I've written several projects and more often then not there is a weird browser quirk, a memory leak, or some other nastiness hidden in the worker implementation. I think my next project I'll go with Emscripten pthreads implementation and see if it's better.
Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer
#69I kept finding myself needing to toss stuff in a background thread, and ended up making this: https://github.com/icodeforlove/task.js It makes wrangling multiple workers much easier, and doesn't require you to have external JS files. (also works in node.js) demo: http://s.codepen.io/icodeforlove/debug/ZOjBBB/NjrYzwzWdzLA
Looks impressive, well thought out interface. That's also an impressive grid of browser compatibility.
Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer
#70Earlier quoted context omitted.
I'm pretty sure you're wrong. At the bare minimum, setTimeout must use a clock in another thread, since it doesn't block your primary thread code. I'm fairly sure that most of all of the JavaScript APIs that use callbacks are using additional threads, including the ubiquitous XMLHttpRequest.
I'm not sure how the inner plumbing works. But since the queue just pops onto the stack, there's no true parallelism and therefore no optimization opportunity. That being said, I'm not sure you're correct. There is no concern of blocking the main thread, since functions queued up via. `setTimeout()` are not tracked by some non-blocking timer. The queue is only inspected if the stack is empty. So if anything is happen…
You can definitely block the main thread. XHR requests can be run synchronously by calling .open() with false as the third argument. And when you do asynchronous XHR requests, the browser can and will run multiple requests in parallel. Of course, the callbacks just get added to the event queue and run one at a time to completion on the main thread. And granted, it's hard to call this an "optimization opportunity," since you should almost never make synchronous XHR requests anyway.