வேலைத்தொடர் நூல்களை (worker threads) எப்போது மற்றும் எவ்வாறு பயன்படுத்துவீர்கள்?

Question

Accepted Answer

**Worker threads** Node ஐ **தனித்தனி நூல்களில்** JavaScript ஐ இயக்க அனுமதிக்கிறது, உண்மையான இணையாக்க செயல்பாட்டுடன் — Node இன் மிகப்பெரிய வரம்பை தீர்க்கிறது: CPU-தீவிர வேலை ஒரே பிரதான நூலை (மற்றும் எனவே அனைத்து கோரிக்கைகளை) தடுக்கிறது. கனமான கணக்கீட்டிற்கு அவற்றைப் பயன்படுத்தவும், I/O க்கு அல்ல (event loop ஏற்கனவே திறமையாகக் கையாளுகிறது).

## அவர்கள் தீர்க்கும் சிக்கல்

```js
// ❌ this CPU-heavy work BLOCKS the event loop → all requests freeze for its duration
app.get("/hash", (req, res) => {
  const result = expensiveComputation(); // e.g. heavy crypto, image processing
  res.json(result); // meanwhile, no other request can be handled
});
```

Node உங்கள் JS ஐ ஒரு நூலில் இயக்குகிறது. ஒரு நீண்ட ஒத்திசைக்கப்பட்ட கணக்கீடு **எல்லாவற்றையும்** தடுக்கிறது — event loop அது முடிந்த வரை மற்ற கோரிக்கைகளை செயல்படுத்த முடியாது. Worker threads அந்த வேலையை பிரதான நூலிலிருந்து நகர்த்துகிறது.

## தொழிலாளர் நூல் பயன்படுத்துதல்

```js
// main.js
import { Worker } from "worker_threads";

// the main thread stays free to handle other requests while this runs
const result = await runHeavyTask({ numbers: [...] });
```

```js
// worker.js — runs in parallel, on its own thread
import { workerData, parentPort } from "worker_threads";

const result = expensiveComputation(workerData); // doesn't block the main thread
parentPort.postMessage(result);                    // send the result back
```

தொழிலாளர் சுயாதீனமாக இயங்குகிறது; பிரதான நூல் கோரிக்கைகளைப் பরிவேளையும் முடிந்தபின் ஒரு செய்தியின் மூலம் ফলাபீடு பெறுகிறது.

## எப்போது பயன்படுத்த வேண்டும் (மற்றும் பயன்படுத்தக் கூடாது)

```text
✓ USE for CPU-bound work: image/video processing, encryption, compression,
  big data parsing, complex calculations, ML inference
✗ DON'T use for I/O (DB, files, HTTP) — the async event loop already handles
  that efficiently; a worker would add overhead for no benefit
```

விதி: **CPU-வரம்பிற்கு worker, I/O-வரம்பிற்கு event loop.**

## Worker threads vs child_process vs cluster

```text
worker_threads → share memory (efficient data passing), in-process threads — CPU work
child_process  → separate OS processes, run other programs — heavier isolation
cluster        → fork the whole server across CPUs — scale request handling
```

## இது ஏன் முக்கியமாக உள்ளது

Worker threads Node இன் முக்கிய பலவீனத்தைக் கொண்டாடுகிறது — CPU-வரம்பிய பணிகள் ஒক்கப-நூலாக்கப்பட்ட event loop ஐ தடுக்கிறது மற்றும் அனைத்து ஒத்திசைக்கப்பட்ட கோரிக்கைகளை முறிக்கிறது.

கனமான கணக்கீட்டை ஒரு worker க்கு மாற்றுவதை அறிந்து (பிரதான நூலை பதிலளிக்கவல்ல வைத்திருப்பது), மற்றும் குறிப்பாக **எப்போது** அவற்றைப் பயன்படுத்த வேண்டும் (CPU-வரம்பு மட்டுமே, I/O க்கு ஒருபோதும் அல்ல), Node சேவையை இடைக்கால கனமான செயலாக்கத்தை எதிர்கொள்ள அனுமதிக்கிறது Node மূল்যவানவாக்கும் ஒத்திசைவை குரியாப் செய்யாமல்.

உৎপাദனத்தில் workers ஐ பூலிங் செய்வதற்கு, Piscina போன்ற நூலகங்கள் ஒரு நூல் பூலை திறமையாக நிர்வகிக்கின்றன.