إنشاء خيوط Worker وتمرير الرسائل

Node.js runs your JavaScript on a single thread. That is great for I/O-bound work (HTTP, DB, files) because the event loop never blocks. But a CPU-bound task — image resizing, hashing, parsing huge payloads, crypto — runs synchronously and freezes the entire server until it finishes.

• I/O-bound → stay on the event loop, use async APIs.
• CPU-bound → offload to a Worker thread so the main thread keeps serving requests.

The worker_threads module lets you run JavaScript in parallel on separate OS threads, each with its own V8 isolate and event loop.

You create a thread with new Worker(filename). The file runs on a fresh thread. Use isMainThread to make one file behave differently depending on where it runs.

Below, the main thread spawns a worker that points back to the same file. The worker branch does the work and exits.

To hand input to a worker at creation time, pass workerData in the options object. Inside the worker, read it from the worker_threads module.

• workerData is cloned (structured clone), not shared — mutating it in the worker does not affect the main thread.
• Use it for the initial job parameters: a file path, a number range, config.

workerData is one-way and one-time. For results, use the message channel that every worker has built in:

• Inside the worker: parentPort.postMessage(value) sends data to the parent.
• On the main thread: worker.on('message', cb) receives it.

Messages are asynchronous and structured-cloned, so the main thread stays responsive while the worker computes.

The channel works both directions. The parent can worker.postMessage() and the worker listens with parentPort.on('message', ...). This turns a worker into a long-lived service that processes many jobs instead of one.

Notice the worker stays alive listening for messages; you must explicitly tell it to stop (here, a null sentinel triggers process.exit).

In backend code you usually want a clean async function: call it, await a result. Wrap the worker lifecycle in a Promise, resolving on message and rejecting on error or a non-zero exit.

This pattern is the foundation of any worker-pool: one promise per task.

Messages are copied using the structured clone algorithm, not JSON.stringify. That means you can send more than plain JSON.

• Supported: objects, arrays, Map, Set, Date, RegExp, ArrayBuffer, typed arrays, BigInt.
• Not supported: functions, class instances with methods, DOM-like objects, anything with closures — these throw a DataCloneError.

Cloning large objects costs CPU and memory. For big binary buffers, prefer transferring instead of copying (next scene).

For large binary data, copying is wasteful. Pass a transfer list as the second argument to postMessage. Ownership of the ArrayBuffer moves to the other thread — zero-copy — and the buffer becomes unusable on the sender (its byteLength becomes 0).

Use this for image bytes, file chunks, or any megabyte-scale payload to avoid duplicating memory.

Beyond the built-in parentPort, you can create your own channel with new MessageChannel(). It gives two linked ports, port1 and port2. Keep one, transfer the other into a worker, and now you have a dedicated pipe — useful for separating control messages from data, or for worker-to-worker communication.

A MessagePort is itself transferable, so you send it inside workerData or a message with a transfer list.

A worker can crash. Always wire up its lifecycle events so a failed job does not silently hang a request:

• 'error' — an uncaught exception inside the worker.
• 'exit' — fired once; code is non-zero on failure.
• 'messageerror' — a message could not be deserialized.

To stop a worker from the main thread, call worker.terminate() (returns a promise). Unterminated workers keep the process alive.

In a real Node.js backend you do not spawn a worker per request — thread startup is expensive. Instead:

• Keep a small pool of long-lived workers (often os.cpus().length).
• Send each CPU-bound job over postMessage and match results by an id.
• Reserve workers for genuinely CPU-bound work; leave I/O on the event loop.

This snippet shows the per-worker message protocol using an id to correlate request and response — the core idea every pool library (like piscina) builds on.

You must send a 50 MB image buffer to a worker for processing and you want to avoid duplicating that memory. Which approach is correct?

You now know how to spawn workers and move data between threads:

• Spawn with new Worker(file, { workerData }); branch on isMainThread.
• Send results with parentPort.postMessage() and receive via worker.on('message') — the channel is two-way.
• Messages use structured clone (richer than JSON, but no functions); large buffers should be transferred via a transfer list for zero-copy.
• Create extra pipes with MessageChannel and transfer a MessagePort for side or worker-to-worker channels.
• Always handle error/exit and call terminate(); in production use a pool with id-correlated messages rather than one worker per request.