Or use ClojureScript with core.async - which implements a go-like concurrency model. (Not saying that's fully or equivalent, or meant to denigrate this interesting work.)
Concurrent JavaScript: It can work
131–140 of 189 posts
Re: Concurrent JavaScript: It can work
#132Earlier quoted context omitted.
Event loops have these too, they just go by different names: * non-determinism -> order in which setTimeouts run * race conditions -> callbacks happen in an unexpected order * deadlock -> broken callback chain
Are you sure that setTimeouts are run in a non-deterministic order? Callbacks can only come back in an unexpected order if you are using I/O. A broken callback chain is not the traditional definition of "deadlock".
> Are you sure that setTimeouts are run in a non-deterministic order?
Certainly, if they are issued from different callbacks. :-) And in relation to how they may happen to be interleaved with I/O.
Also add to the non-determinism bucket: the order in which messages arrive from separate Workers.
> Callbacks can only come back in an unexpected order if you are using I/O.
Which abounds and takes many forms both in the browser and node.js.
> A broken callback chain is not the traditional definition of "deadlock".
Indeed, but it is the same class of developer hazard at play: waiting for an event to happen than will never come. Admittedly, only a subset of dropped callback chains correspond to the strict definition of deadlock: those where a chain is involved in marking a state/resource as available.
For example: I ignore the next button press on a ui that disables the button pending a reply because I accidentally failed to update the button state when a network request failed.
Re: Concurrent JavaScript: It can work
#133Earlier quoted context omitted.
Are you sure that setTimeouts are run in a non-deterministic order? Callbacks can only come back in an unexpected order if you are using I/O. A broken callback chain is not the traditional definition of "deadlock".
> Are you sure that setTimeouts are run in a non-deterministic order? Certainly, if they are issued from different callbacks. :-) And in relation to how they may happen to be interleaved with I/O. Also add to the non-determinism bucket: the order in which messages arrive from separate Workers. > Callbacks can only come back in an unexpected order if you are using I/O. Which abounds and takes many forms both in the br…
> Certainly, if they are issued from different callbacks. :-) And in relation to how they may happen to be interleaved with I/O.
That's non determinism from I/O, not from the callback or the setTimeout. setTimeouts are called in order based on schedule time.
And you can't blame non-determinism in JS on I/O. No language in existence is deterministic based on that measure.
Re: Concurrent JavaScript: It can work
#134I feel like most of the comments here are ignoring the fact that this is a straw man proposal, as the blog post emphasises several times.
They aren't proposing to add threads to JS in exactly this manner. They're pointing out that it would be technically feasible, for WebKit at least, and wouldn't add any unnecessary overhead. The specific proposal is just a starting point for discussion.
Re: Concurrent JavaScript: It can work
#135Earlier quoted context omitted.
Do you need to run your server in a browser?
No, but it's very nice to be able to share code for things like view rendering or form validation between the server and client without jumping through hoops.
So you use language X. Compile it and run it natively on server, compile it to wasm and run that in the browser.
Re: Concurrent JavaScript: It can work
#136Earlier quoted context omitted.
As someone who writes a lot of concurrent and parallel code, I can tell you it's easier to do it if the language is not imposing artificial constraints. Also, most kinds of concurrency models will probably require the underlying VM to support some kind of shared memory. That's what this post is about.
User-land Transferrables would obviously need to be implemented with shared memory, otherwise you could just use the existing structured clone operation. This post isn't just about an underlying shared memory model, concurrent access to objects and variables is exposed to users, and enabled by default. That's a huge footgun that I thought the PL world was moving away from.
I personally love the idea of of transferable objects, this could work very well in an event driven architecture.
Re: Concurrent JavaScript: It can work
#137Earlier quoted context omitted.
> Are you sure that setTimeouts are run in a non-deterministic order? Certainly, if they are issued from different callbacks. :-) And in relation to how they may happen to be interleaved with I/O. Also add to the non-determinism bucket: the order in which messages arrive from separate Workers. > Callbacks can only come back in an unexpected order if you are using I/O. Which abounds and takes many forms both in the br…
> Certainly, if they are issued from different callbacks. :-) And in relation to how they may happen to be interleaved with I/O. That's non determinism from I/O, not from the callback or the setTimeout. setTimeouts are called in order based on schedule time. And you can't blame non-determinism in JS on I/O. No language in existence is deterministic based on that measure.
This seems rather racy in Chrome, despite the I/O being deferred to the end :-)
(function() {
var x = '';
setTimeout(function() { setTimeout(function() { x += 'a'; }, 6); }, 4);
setTimeout(function() { setTimeout(function() { x += 'b'; }, 5); }, 5);
setTimeout(function() { console.log(x); }, 50);
})();
Concurrency introduces another source of non-determinism. But just as good programs use care with the ideally limited amount of code responding to events, good concurrent programs use similar care with access to shared state.
I'm unsure if the strawman syntax proposed encourages that care, but it is interesting that it can at least be done without breaking basic safety + performance. With SharedArrayBuffer on the way, we'll get all the non-determinism of parallel execution peeping through to JS without a particularly JS friendly syntax, so it's at least worth thinking about if something should be added to JS.
Re: Concurrent JavaScript: It can work
#138Yeah, and lets have the gazillion scripts, loaded by your usual favourite news site, spawn 10 threads each... For browsers, this is a bad idea. The biggest advantage of the event loop approach is that it is somewhat deterministic. With threads, that determinism goes out of the window. Lock-management? No way I do that for Browsers. I will quit working on client-side code if that is becoming a requirement! Threads for…
Whether it's a good addition to the language or not is debatable, but as a browser feature, it sounds terrifying. Browsers have a huge attack surface as it is (I mean, WebGL is a thing – exposing GPU drivers to random untrusted code on the internet, what a brilliant idea...), and exposing threading will only make it worse. Every single API would have to be carefully audited and made thread-safe, and I'm sure that man…
Which is why the proposal specifically says that only a few DOM APIs would be exposed to background threads (Like console.log())
Re: Concurrent JavaScript: It can work
#139One other thing to consider, the SharedArrayBuffer can only carry limited data types, it's not a shared object. I used Flash's SharedArrayBuffer and found it was very limited in what you could use it for.
Re: Concurrent JavaScript: It can work
#140Earlier quoted context omitted.
The event loop doesn't allow you to do a computation concurrently with handling user events, so it's not at all a proper concurrency model.
It's a proper concurrency model , it's just not an efficient one when it comes to execution. Concurrency has (at least) two components: design concurrency, execution concurrency. The event loop mechanism in JavaScript allows you to do effective concurrent design . It does not provide for concurrent execution . This is the primary distinction in academic CS between concurrency and parallelism.
The event loop mechanism in JavaScript is not well suited to designing OR executing a computation concurrently. Try replacing a for loop in numeric code with anything that allows for events to be handled. It's extremely awkward.