Talk to your workers, and they will talk back. What are Worker Threads? Node.js Worker Threads allow concurrent execution of JavaScript code. If you are familiar with the Unix thread model, you know that for every process group there is a . A similar model is used for Worker Threads as will be shown. parent process and several child processes Why would you use them? If you have several CPU intensive tasks that need to be done, and those tasks operate independently of each other, then threads allow tasks to run in parallel, saving time. (You don’t need worker threads for I/O processing — this is something that Node.js non-blocking I/O model handles capably already.) For example, I have been working (slowly) on a for the (a.k.a., UCI). One of the things I want to do is pool several chess engines and have them run independently. GraphQL wrapper Universal Chess Interface Creating a worker thread There’s really nothing to it! All that is required is a Node version > 10.5.0. The 10.x versions of Node require the flag to be passed on the command line, but I am running version 11.11.0 and did not have to do that. --experimental-worker Here’s the example given at the for Worker Threads: start of the documentation const {Worker, isMainThread, parentPort, workerData} = require('worker_threads'); if (isMainThread) {module.exports = function parseJSAsync(script) {return new Promise((resolve, reject) => {const worker = new Worker(__filename, {workerData: script});worker.on('message', resolve);worker.on('error', reject);worker.on('exit', (code) => {if (code !== 0)reject(new Error(`Worker stopped with exit code ${code}`));});});};} else {const { parse } = require('some-js-parsing-library');const script = workerData;parentPort.postMessage(parse(script));} Not terribly exciting and a little cryptic. The stuff imported from ‘worker_threads’ is: : a class Worker : true if this is the master process, false otherwise isMainThread : the communication port between parent and worker parentPort : a clone of the data passed to the thread’s Worker constructor. workerData Here, the main thread exports a method that takes some JavaScript and hands it off to a worker thread to process. We know we’re the main thread if is true. Otherwise, we are the worker thread ( block), and we parse the script and returned the result of that back to the parent thread using the Worker method . isMainThread else{} postMessage() If that’s still confusing, here’s a that is perhaps easier to understand. link to another example Talking to a worker thread So far, the only data the worker receives is the sent form the constructor arguments. The main thread gets a message from the worker in the above example, and that message is some parsed JavaScript. workerData That’s pretty , especially since the worker, as soon as it gets its : boring workerData does its thing, sends the result back to the main thread, quits. For my planned chess engine workers, there’s going to be a lot of interaction (via UCI) that will be ongoing for as long as there are games to set up, moves to be made, and chess analysis to be done. I will write about the details of that in the future, but the title of this post says “Simple”, so I’ll illustrate bidirectional interaction with a basic worker. First, the worker code: So all this mostly does is echo the messages it’s given, with the exception of “ ”, which I’ll get to in a minute. exit The main thread that creates the worker is similar to the examples noted earlier, but no Promise is involved: The main thing to note is that several messages are being sent to the worker, besides the one that is sent via the Worker constructor (i.e., workerData). So what happens when I run this? Let’s map these message lines with lines of code: comes from line 19 of index.js {isMainThread: true} : line 14 of service.js (the worker thread). { incoming: { start: “let’s begin”, isMainThread: false } } { incoming: { going: 'once' } }{ incoming: { going: 'twice' } }{ incoming: { going: 'three times' } } These all come from line 10 of service.js is line 7 of service.js { incoming: ‘sold!’ } brings us back to index.js, line 9. Worker stopped with exit code 0 Exiting the thread I added the ability to exit the worker thread from the main thread. When the main thread posts an “ ” message, the worker closes the port. This triggers an exit event back in the main thread, and the exit status is noted (line 9). exit What happens if you try to post another message after the worker has exited? Line 14 of index.js tries to do just that. Note that the message does not appear in the console output. Done! There’s a lot more to worker threads than this, but that about wraps it up for “simple”. Full code can be found . here
