event loop — task আর microtask: এক thread-এ অনেক কাজ

১ · এক জন দোকানি, অনেক অর্ডার — synchronous বনাম asynchronous

পর্ব ৫-এ দেখেছেন, JavaScript engine কোড চালায় একটি call stack দিয়ে, আর একসময়ে একটিই কাজ করে। অথচ একটি সাধারণ ওয়েব পাতা একই সময়ে বোতামের ক্লিকের অপেক্ষা করে, একটি timer গুনছে, আর সার্ভার থেকে ডেটা আনছে। এক হাতে এত কাজ কীভাবে? এই পর্বের পুরো উত্তর একটি শব্দে — event loop. তবে শব্দটা মুখস্থ করার আগে ছবিটা পরিষ্কার করি।

দুটি শব্দ আলাদা করে বুঝে নিন:

এখানে একটি সূক্ষ্ম কিন্তু জরুরি পার্থক্য আছে: concurrency আর parallelism. চায়ের দোকানি একসাথে পাঁচটি অর্ডার “চালু” রাখেন — এটা concurrency: অনেক কাজ একই সময়সীমায় এগোচ্ছে, কিন্তু যেকোনো মুহূর্তে হাত চলছে একটিতেই। Parallelism মানে সত্যিই একই মুহূর্তে দুটি কাজ — তার জন্য দ্বিতীয় দোকানি (আরেকটি thread বা CPU core) লাগে। JavaScript-এর main thread concurrency দেয়, parallelism নয়। Parallelism আসে Web Worker দিয়ে — পর্ব ৪২-এ।

২ · Blocking — একটি লম্বা কাজ পুরো পাতা থামিয়ে দেয়

যেহেতু thread একটিই, কোনো একটি কাজ বেশিক্ষণ stack দখল করে রাখলে বাকি সবাইকে অপেক্ষা করতে হয়। একে বলে blocking. ব্রাউজারে এই thread-কে বলে main thread, আর সেখানে শুধু আপনার কোড নয়, ক্লিক সামলানো, style হিসাব, layout, পাতা আঁকা — সবই চলে। তাই main thread আটকানো মানে পাতাটাই আটকানো।

একটি অনলাইন দোকানের “অর্ডার দিন” বোতাম ভাবুন। ক্লিক করলে কোড কার্টের প্রতিটি পণ্যে ডিসকাউন্ট, ভ্যাট আর ডেলিভারি চার্জ হিসাব করে — ধরুন সব মিলিয়ে ৮০০ মিলিসেকেন্ড লাগে:

orderBtn.addEventListener("click", () => {
  statusEl.textContent = "প্রসেস হচ্ছে…";      // ১. লেখা বদলাল (DOM-এ)
  const total = calculateEverything(cart);     // ২. ভারী হিসাব — ৮০০ ms
  statusEl.textContent = `মোট: ${total} টাকা`; // ৩. আবার বদলাল
});

নিচের ডায়াগ্রামে দেখুন, ভারী কাজ চলার মাঝে একটি ক্লিক এলে ঠিক কী হয়:

আপনার ব্রাউজারের console-এ নিচের কোডটি চালিয়ে দেখতে পারেন। সময় মাপার দরকার নেই — শুধু লেখার ক্রম দেখুন:

setTimeout(() => console.log("৩. timer — ০ ms চেয়েছিলাম"), 0);

let sum = 0;
for (let i = 0; i < 200_000_000; i++) sum += i;   // কয়েকশো ms ব্যস্ত

console.log("১. লুপ শেষ");
console.log("২. script শেষ");

// প্রত্যাশিত আউটপুট:
// ১. লুপ শেষ
// ২. script শেষ
// ৩. timer — ০ ms চেয়েছিলাম

৩ · Event loop-এর অংশগুলো — stack, host, দুই রকম queue আর rendering

এবার পুরো যন্ত্রটির অংশগুলো নাম ধরে চিনে নিই। ব্রাউজারে event loop-এর নিয়ম লেখা আছে HTML Standard-এ (WHATWG); ECMAScript ভাষা শুধু বলে Promise-এর কাজ একটি “job” queue-তে যাবে, কখন চলবে তা ঠিক করে host.

লক্ষ করুন, task queue আসলে একাধিক থাকতে পারে — timer-এর একটি, ব্যবহারকারীর ইনপুটের একটি, নেটওয়ার্কের একটি। Spec ব্রাউজারকে স্বাধীনতা দেয় কোন queue থেকে পরের task নেবে; তাই অনেক ব্রাউজার ক্লিক বা কী-চাপের মতো ইনপুটকে আগে সুযোগ দেয়। কিন্তু একই queue-এর ভেতরে ক্রম সবসময় আগে-এলে-আগে।

পুরো নিয়মটা একটি লুপ হিসেবে লিখলে এমন দাঁড়ায় (সরল ছদ্মকোড, আসল কোড নয়):

while (true) {
  const task = pickOldestTask();      // একটি task (না থাকলে অপেক্ষা)
  if (task) run(task);                // শেষ পর্যন্ত চালাও — মাঝে কেউ ঢুকবে না

  while (microtaskQueue.length > 0) { // সব microtask, নতুন যোগ হলেও
    run(microtaskQueue.shift());
  }

  if (timeToRender()) {               // সাধারণত ~১৬ ms পরপর
    runAnimationFrameCallbacks();     // requestAnimationFrame
    styleLayoutPaint();
  }
}

প্রতিটি callback শেষ পর্যন্ত চলে, মাঝখানে অন্য কোনো JavaScript ঢুকতে পারে না — একে বলে run-to-completion. এটি একটি বড় সুবিধা: আপনার function চলার সময় অন্য কোনো callback এসে variable বদলে দেবে না, তাই Java বা C++-এর মতো lock লাগে না। আবার এটিই blocking-এর কারণ।

requestAnimationFrame — আঁকার ঠিক আগের মুহূর্ত

অ্যানিমেশনের জন্য setTimeout(draw, 16) লেখা পুরোনো অভ্যাস। Timer পর্দার আঁকার সাথে তাল মেলায় না — কখনো এক ফ্রেমে দুবার চলে, কখনো একবারও না, ফলে ঝাঁকুনি। requestAnimationFrame (rAF) ব্রাউজারকে বলে, “পরের বার আঁকার ঠিক আগে এটা চালাবেন”। তাই প্রতি ফ্রেমে ঠিক একবার চলে, আর tab লুকানো থাকলে সাধারণত থেমে থাকে — ব্যাটারিও বাঁচে। বিস্তারিত অ্যানিমেশন এই কোর্সের বিষয় নয়; শুধু মনে রাখুন rAF event loop-এর rendering ধাপের অংশ, task বা microtask নয়।

৪ · ক্রমের ধাঁধা — ধাপে ধাপে সমাধান

পর্ব ৫-এ একটি সহজ ধাঁধা দেখেছিলেন: sync → Promise → setTimeout. এবার একটু কঠিন রূপ — একটি task-এর ভেতর থেকে microtask তৈরি হলে কী হয়? দ্বিতীয় timer আগে চলবে, না নতুন microtask? চালানোর আগে নিজে খাতায় উত্তর লিখুন, তারপর “পরে” চাপুন।

1console.log("A");2setTimeout(() => {3  console.log("D");4  queueMicrotask(() => console.log("E"));5}, 0);6setTimeout(() => console.log("F"), 0);7Promise.resolve().then(() => console.log("C"));8console.log("B");

এবার একটি গল্পে বাঁধা উদাহরণ নিজে চালিয়ে দেখুন। একটি অনলাইন দোকানে অর্ডার এলে কয়েকটি কাজ হয় — কিছু সাথে সাথে, কিছু microtask হিসেবে, কিছু timer দিয়ে। এখানে async function আর await-ও আছে:

console.log("অর্ডার এল");

setTimeout(() => {
  console.log("কুরিয়ারকে খবর (task ১)");
  Promise.resolve().then(() => console.log("গ্রাহককে SMS (task ১-এর microtask)"));
}, 0);
setTimeout(() => console.log("রিভিউ চাওয়া (task ২)"), 0);

queueMicrotask(() => console.log("স্টক কমানো (queueMicrotask)"));

async function pay() {
  console.log("পেমেন্ট শুরু (async function-এর sync অংশ)");
  await null;
  console.log("পেমেন্ট নিশ্চিত (await-এর পরের অংশ)");
}
pay();

Promise.resolve()
  .then(() => console.log("ইনভয়েস তৈরি (then ১)"))
  .then(() => console.log("ইমেইল পাঠানো (then ২)"));

console.log("script শেষ");

৫ · Microtask-এর ফাঁদ, আর setTimeout 0-এর আসল মানে

“প্রতিটি task-এর পরে সব microtask” — নিয়মটির একটি অন্ধকার দিক আছে। একটি microtask যদি আরেকটি microtask যোগ করে, আর সেটি আরেকটি… তাহলে queue কখনো খালি হয় না। Event loop সেখানেই আটকে থাকে: কোনো task চলে না, পাতাও আঁকা হয় না। একে বলে microtask starvation. নিচের ডায়াগ্রামে দুটি “লুপ” তুলনা করুন — একটি queueMicrotask দিয়ে, আরেকটি setTimeout দিয়ে।

setTimeout(fn, 0) — “এখনই” নয়, “পরের কোনো task-এ”

setTimeout-এর দেরি একটি ন্যূনতম সময়, নিশ্চিত সময় নয়। বাস্তবে আরও কয়েকটি নিয়ম আছে:

• নেস্টিংয়ের সীমা: HTML Standard অনুযায়ী timer-এর ভেতর থেকে timer, তার ভেতর থেকে আবার timer — এভাবে নেস্টিং পাঁচ স্তর ছাড়ালে ৪ ms-এর কম দেরি চাইলেও ব্রাউজার অন্তত ৪ ms ধরে নেয়। একে বলে timer clamping. উপরের task-লুপ তাই কয়েকবার পরেই প্রতি ঘুরে অন্তত ৪ ms নেয়।
• লুকানো tab: পেছনের tab-এ ব্রাউজার timer অনেক ধীর করে দেয় (প্রায়ই সেকেন্ডে একবার বা তারও কম) — ব্যাটারি বাঁচাতে।
• Node.js: setTimeout(fn, 0) আসলে ১ ms ধরা হয়; দেরি ১-এর কম বা ২^৩১−১ ms-এর বেশি দিলে Node সেটিকে ১ করে দেয়।
• সবার ওপরে: stack ব্যস্ত থাকলে কোনো timer-ই চলতে পারে না — অংশ ২-এর লুপের উদাহরণ মনে করুন।

তাহলে setTimeout(fn, 0) কেন লেখা হয়? মানে হলো: “চলমান কাজটা শেষ হোক, ব্রাউজার একবার শ্বাস নিক (আঁকা, ইনপুট), তারপর আমাকে চালাবেন”। কাজ পিছিয়ে দেওয়ার এটি পুরোনো ও কার্যকর উপায় — শুধু “০” সংখ্যাটা বিভ্রান্তিকর। Timer আর callback-এর বিস্তারিত পর্ব ৩২-এ।

৬ · Long task, INP আর ভারী কাজ টুকরো করা

Main thread-কে ৫০ মিলিসেকেন্ডের বেশি আটকে রাখা যেকোনো task-কে বলে long task. কেন ৫০? সাধারণ নির্দেশিকা হলো ক্লিকের সাড়া ১০০ ms-এর মধ্যে দেখা গেলে মানুষ সেটিকে “তাৎক্ষণিক” মনে করে; task ৫০ ms-এর মধ্যে রাখলে বাকি অর্ধেক সময় ইনপুট সামলানো আর আঁকার জন্য থাকে।

Google-এর Core Web Vitals-এ সাড়া দেওয়ার মাপকাঠি এখন INP (Interaction to Next Paint) — ২০২৪ সালের মার্চে এটি FID-এর জায়গা নিয়েছে। INP মাপে: পাতায় থাকার পুরো সময়ের ক্লিক, ট্যাপ আর কী-চাপের মধ্যে প্রায় সবচেয়ে ধীরটিতে, ইনপুট থেকে পরের বার পর্দা আঁকা পর্যন্ত কত সময় লাগল। ২০০ ms বা কম হলে “ভালো”, ৫০০ ms-এর বেশি হলে “খারাপ”। অংশ ২-এর “অর্ডার দিন” বোতামের INP প্রায় ৮০০ ms — স্পষ্টতই খারাপ। DevTools দিয়ে INP আর long task খুঁজে বের করা শিখবেন পর্ব ৫৩-এ।

INP-এর সময় তিন ভাগে ভাগ হয়: input delay (অন্য task চলছিল বলে আপনার handler শুরু হতে দেরি), processing (আপনার handler নিজে), আর presentation delay (style, layout, paint). তিনটির প্রতিটিই long task দিয়ে বাড়ে।

সমাধান: কাজ টুকরো করুন, মাঝে মাঝে main thread ছেড়ে দিন

পুরো হিসাব একবারে না করে ছোট ছোট টুকরোয় করুন, আর প্রতি টুকরোর পর একটি নতুন task-এ চলে যান — যাতে ফাঁকে ব্রাউজার ক্লিক সামলাতে আর পাতা আঁকতে পারে। একে বলে main thread-কে ছেড়ে দেওয়া (yielding), আর কাজ ভাঙাকে chunking:

function yieldToMain() {
  if (globalThis.scheduler?.yield) return scheduler.yield(); // নতুন ব্রাউজারে
  return new Promise((resolve) => setTimeout(resolve, 0));    // বাকি সবখানে
}

orderBtn.addEventListener("click", async () => {
  statusEl.textContent = "প্রসেস হচ্ছে…";
  await yieldToMain();                      // আগে লেখাটা পর্দায় আসুক

  let total = 0, last = performance.now();
  for (const item of cart) {
    total += priceWithDiscount(item);
    if (performance.now() - last > 40) {    // ~৪০ ms পরপর বিরতি
      await yieldToMain();
      last = performance.now();
    }
  }
  statusEl.textContent = `মোট: ${total} টাকা`;
});

৭ · Node.js-এর event loop — phase, nextTick আর setImmediate

Node.js-এও একই মূল চিন্তা: আপনার JavaScript একটি thread-এ, অপেক্ষার কাজ বাইরে। এখানে বাইরের কাজ করে libuv নামের একটি C library — নেটওয়ার্কের জন্য অপারেটিং সিস্টেমের ব্যবস্থা (Linux-এ epoll, macOS-এ kqueue, Windows-এ IOCP), আর ফাইল পড়া, DNS খোঁজা বা কিছু crypto-র মতো কাজের জন্য একটি ছোট thread pool (ডিফল্ট ৪টি thread). তবে Node-এর loop ব্রাউজারের চেয়ে বেশি কাঠামোবদ্ধ — প্রতিটি ঘুর কয়েকটি নির্দিষ্ট phase-এ ভাগ করা:

আর প্রতিটি callback শেষ হওয়ার পরে, পরের callback-এর আগে, Node দুটি লাইন খালি করে — প্রথমে process.nextTick-এর queue, তারপর Promise-এর microtask queue. (Node 11 থেকে এটি প্রতিটি timer বা immediate callback-এর পরেই হয়, ব্রাউজারের মতো; তার আগে পুরো phase শেষে হতো।) নামের সাথে কাজের মিল নেই, খেয়াল করুন: nextTick আসলে “পরের tick”-এ নয়, চলমান কাজের ঠিক পরেই চলে; আর setImmediate “এখনই” নয়, check phase-এ চলে। Node-এর ডকুমেন্টেশনও স্বীকার করে নামগুলো উল্টো হওয়া উচিত ছিল।

const fs = require("fs");

console.log("A: sync কোড শুরু");
setTimeout(() => console.log("E: timers phase — setTimeout"), 0);
Promise.resolve().then(() => console.log("D: promise microtask"));
process.nextTick(() => console.log("C: process.nextTick"));
console.log("B: sync কোড শেষ");

fs.readFile(__filename, () => {
  console.log("F: poll phase — ফাইল পড়া শেষ");
  setTimeout(() => console.log("J: পরের ঘুরে timers"), 0);
  setImmediate(() => console.log("I: check phase — setImmediate"));
  Promise.resolve().then(() => console.log("H: promise"));
  process.nextTick(() => console.log("G: nextTick"));
});

এক thread-এ হাজার request — আর সবচেয়ে বড় ভুল

একটি Node.js সার্ভারে প্রতিটি request আসে একটি task হিসেবে (poll phase-এ)। Handler ডেটাবেসকে প্রশ্ন পাঠিয়ে await করলে thread মুক্ত হয়ে যায়, আর পরের request সামলাতে পারে। তাই একটি thread-ই একসাথে হাজার হাজার সংযোগ ধরে রাখতে পারে — যতক্ষণ প্রত্যেকে বেশিরভাগ সময় অপেক্ষাই করে। বিকাশ-এর মতো কোনো পেমেন্ট সেবার কাউন্টারে একজন কর্মী যদি প্রতিটি গ্রাহকের ফর্ম জমা দিয়ে উত্তর আসা পর্যন্ত বসে না থেকে পরের জনকে ডাকেন — সেই রকম।

const http = require("node:http");
const crypto = require("node:crypto");

http.createServer((req, res) => {
  // ❌ sync hash: প্রতিটি request-এ main thread কয়েকশো ms আটকে যায়
  const hash = crypto.pbkdf2Sync("pass", "salt", 600_000, 64, "sha512");
  res.end(hash.toString("hex").slice(0, 16));
}).listen(3000);

// ✅ async রূপ: ভারী কাজ libuv-এর thread pool-এ, main thread মুক্ত
// crypto.pbkdf2("pass", "salt", 600_000, 64, "sha512", (err, hash) => { ... });

৮ · async/await-ও microtask, আর event loop চোখে দেখার উপায়

মডিউল ৫-এর বাকি পর্বগুলোর সবকিছু এই পর্বের নিয়মের ওপর দাঁড়িয়ে। পর্ব ৩২-এর callback আর timer — task. পর্ব ৩৩-এর Promise — তার then callback microtask. পর্ব ৩৪-এর async function — প্রতিটি await-এ function থেমে যায়, stack খালি করে দেয়, আর অপেক্ষার Promise পূর্ণ হলে বাকি অংশ একটি microtask হিসেবে ফিরে আসে। দেখতে sync কোডের মতো, কিন্তু ভেতরে সেই একই event loop. তাই await লিখলেই কাজ “পেছনে” চলে যায় না — await-এর আগের আর পরের ভারী হিসাব main thread-এই চলে।

পর্ব ৩৫-এর fetch-এ নেটওয়ার্কের অপেক্ষা করে ব্রাউজার; উত্তর এলে Promise পূর্ণ হয়, আর আপনার then বা await-এর পরের অংশ microtask হিসেবে চলে। আর পর্ব ৪২-এর Web Worker — নিজের আলাদা thread, নিজের আলাদা event loop.

চোখে দেখার টুল

• Loupe: Philip Roberts-এর তৈরি একটি ছোট ওয়েব টুল, যেখানে কোড লিখলে call stack, Web API আর callback queue-তে কী ঢুকছে-বেরোচ্ছে, অ্যানিমেশনে দেখা যায়। তিনি এটি দেখিয়েছিলেন JSConf EU 2014-এর বিখ্যাত বক্তৃতা “What the heck is the event loop anyway?”-তে — event loop বোঝার জন্য আজও সবচেয়ে বেশি দেখা ভিডিওগুলোর একটি। (Loupe microtask আলাদা দেখায় না; সেটুকু এই পর্বের ডায়াগ্রাম থেকে নিন।)
• DevTools Performance প্যানেল: Record চেপে পাতায় ক্লিক করুন; main thread-এর সারিতে প্রতিটি task একটি বাক্স, আর ৫০ ms-এর বেশি হলে কোণে লাল দাগ — long task. পর্ব ৫৩-এ বিস্তারিত।
• Node.js: node --cpu-prof দিয়ে profile নেওয়া যায়; আর perf_hooks module-এর monitorEventLoopDelay() মাপে loop কতটা দেরিতে ঘুরছে — সার্ভার আটকে যাচ্ছে কি না বোঝার ভালো সূচক।

৯ · AI-এর যুগে — event loop নিয়ে AI-এর পরিচিত ভুল

Asynchronous কোড লেখায় AI দ্রুত, কিন্তু event loop-এর সূক্ষ্ম নিয়মে প্রায়ই ভুল করে — কারণ ইন্টারনেটে ভুল ব্যাখ্যাও প্রচুর। নিচের ভুলগুলো চিনে রাখুন:

AI-এর async কোড হাতে পেলে — যাচাইয়ের চেকলিস্ট

• আউটপুটের ক্রম নিজে তিন কলামে (আউটপুট, microtask, task) মিলিয়ে দেখেছি, তারপর চালিয়ে নিশ্চিত হয়েছি
• Click handler বা request handler-এ কোনো ভারী sync লুপ, ...Sync function বা বিশাল JSON কাজ নেই
• “বিরতি” দিতে microtask নয়, task (setTimeout / scheduler.yield) ব্যবহার হয়েছে; scheduler.yield থাকলে feature detection আছে
• নিজেকে আবার নির্ধারণ করে এমন microtask বা nextTick লুপ নেই
• কোড কোনো অনিশ্চিত ক্রমের ওপর নির্ভর করে না (setTimeout 0 বনাম setImmediate, দুটি আলাদা নেটওয়ার্ক উত্তর কোনটা আগে আসবে)
• DevTools-এর Performance প্যানেলে long task আছে কি না দেখেছি