multi-core programming using JavaScript?_问答_开发者

So I have this seriously recursive function that I would like to use with my code. The issue is it doesn't really take advantage of dual core machines because js is single threaded. I have tried using webworkers but don't really know much about multicore programming. Would someone point me to some material that could explain how it is done. I googled to find this sample link but its not really much help without documentation! =/

I would be glad if someone coul开发者_运维问答d show me how this could be done without webworkers though! That would be just awesome! =)

I came across this link on whatwg. This is really weird because it explains how to use multicore programming in webworkers etc, but on executing on my chrome browser it throws errors. Same goes with other browsers.

Error: 9Uncaught ReferenceError: Worker is not defined in worker.js

UPDATE (2018-06-21): For people coming here in search of multi-core programming in JavaScript, not necessarily browser JavaScript (for that, the answer still applies as-is): Node.js now supports multi-threading behind a feature flag (--experimental-workers): release info, relevant issue.

Writing this off the top of my head, no guarantees for source code. Please go easy on me.

As far as I know, you cannot really program in threads with JavaScript. Webworkers are a form of multi-programming; yet JavaScript is by its nature single-threaded (based on an event loop).

A webworker is seperate thread of execution in the sense that it doesn't share anything with the script that started it; there is no reference to the script's global object (typically called "window" in the browser), and no reference to any of your main script's variables other than data you send to the thread.

Think as the web worker as a little "server" that gets asked a question and provides an answer. You can only send strings to that server, and it can only parse the string and send back what it has computed.

// in the main script, one starts a worker by passing the file name of the 
// script containing the worker to the constructor. 
var w = new Worker("myworker.js");

// you want to react to the "message" event, if your worker wants to inform
// you of a result. The function typically gets the event as an argument. 
w.addEventListener("message",
    function (evt) {
        // process evt.data, which is the message from the 
        // worker thread
        alert("The answer from the worker is " + evt.data);
    });

You can then send a message (a String) to this thread using its postMessage()-Method:

w.postMessage("Hello, this is my message!");

A sample worker script (an "echo" server) can be:

// this is another script file, like "myworker.js"
self.addEventListener("message", 
    function (evt) {
        var data = JSON.parse(evt.data);
        /* as an echo server, we send this right back */
        self.postMessage(JSON.stringify(data))
    })

whatever you post to that thread will be decoded, re-encoded, and sent back. of course you can do whatever processing you would want to do in between. That worker will stay active; you can call terminate() on it (in your main script; that'd be w.terminate()) to end it or calling self.close() in your worker.

To summarize: what you can do is you zip up your function parameters into a JSON string which gets sent using postMessage, decoded, and processed "on the other side" (in the worker). The computation result gets sent back to your "main" script.

To explain why this is not easier: More interaction is not really possible, and that limitation is intentional. Because shared resources (an object visible to both the worker and the main script) would be subject to two threads interfering with them at the same time, you would need to manage access (i.e., locking) to that resource in order to prevent race conditions.

The message-passing, shared-nothing approach is not that well-known mainly because most other programming languages (C and Java for example) use threads that operate on the same address space (while others, like Erlang, for instance, don't). Consider this:

It is really hard to code a larger project with mutexes (a mutual exclusion mechanism) because of the associated deadlock/race condition complexities. This is stuff that can make grown men cry!
It is really easy in comparison to do message-passing, shared-nothing semantics. The code is isolated; you know exactly what goes into your worker and what comes out of your worker. Deadlocks and race conditions are impossible to achieve!

Just try it out; it is capable of doing interesting things, probably all you want. Bear in mind that it is still implementation defined whether it takes advantage of multicore as far as I know.

NB. I just got informed that at least some implementations will handle JSON encoding of messages for you.

So, to give an answer to your question (it's all above; tl;dr version): No, you cannot do this without web workers. But there is nothing really wrong about web workers aside from browser support, as is the case with HTML5 in general.

As far as I remember this is only possible with the new HTML5 standard. The keyword is "Web-Worker"