الـ event loop والـ microtasks: Node بيعمل كل حاجة بـ thread واحد إزاي

أهلًا بيك. Node بيشغّل الـ JavaScript بتاعك على thread واحد بس. يعني في أي وقت، فيه سطر واحد بس بيشتغل. طب إزاي server واحد بيخدم آلاف الناس في نفس الوقت؟ السر: إنه عمره ما يستنى. أي عملية I O، زي قراية ملف أو query أو request شبكة، بيتبعت لنزام التشغيل، و Node يكمّل، ولما النتيجة تيجي، الـ callback بتاعها بيتحط في طابور. والـ event loop هو اللي بيلف على الطوابير دي بالترتيب. الطوابير دي ليها أولويات، وده بيغيّر ترتيب الـ code بتاعك. setTimeout بـ zero. promise then. process dot nextTick. وسطرين sync. الأرقام اللي في الكلام هي الترتيب اللي هيطلع، خليني أوريك ليه. نشغّل.

console.log("1 sync");

setTimeout(() => console.log("5 timeout"), 0);
Promise.resolve().then(() => console.log("4 promise microtask"));
process.nextTick(() => console.log("3 nextTick"));

console.log("2 sync");

$ node main.js
1 sync
2 sync
3 nextTick
4 promise microtask
5 timeout

واحد واتنين، الـ sync الأول، لأن الملف لازم يخلص. بعدين تلاتة: nextTick، وده طابور خاص بـ Node، أولويته أعلى من أي حاجة. بعدين أربعة: الـ microtask بتاع الـ promise. وفي الآخر خمسة: الـ timer، حتى لو بـ zero. القاعدة: بعد كل callback، Node بيفضّي nextTick كله، وبعده الـ microtasks كلها، وبعدين بس بيروح للطابور اللي بعده. معلومة غريبة بس مهمة. نفس الـ code بالزبط، بس في ملف ESM، يعني dot mjs. نشغّل main dot mjs.

console.log("1 sync");

setTimeout(() => console.log("5 timeout"), 0);
Promise.resolve().then(() => console.log("4 promise microtask"));
process.nextTick(() => console.log("3 nextTick"));

console.log("2 sync");

$ node main.mjs
1 sync
2 sync
4 promise microtask
3 nextTick
5 timeout

المرة دي أربعة قبل تلاتة: الـ promise قبل nextTick! السبب إن ملف ESM الرئيسي نفسه بيتشغّل جُوّه microtask، فبعد ما يخلص، Node بيكمّل الـ microtasks اللي في الطابور قبل ما يوصل لـ nextTick. الدرس هنا: ما تبنيش منطق البرنامج على ترتيب nextTick مقابل promise. لو محتاج ترتيب، استخدم await صريح. الـ event loop نفسه بيلف في مراحل: timers، وبعدين poll اللي فيها callbacks الـ I O، وبعدين check اللي فيها setImmediate، وبعدين يرجع للـ timers. فلو إنتَ جُوّه callback بتاع I O، وعملت setTimeout و setImmediate، مين الأول؟ بنقرا الملف نفسه، وجُوّه الـ callback بنعمل الاتنين. نشغّل.

const fs = require("node:fs");

fs.readFile(__filename, () => {
  console.log("A: جُوّه callback بتاع readFile (poll)");
  setTimeout(() => console.log("C: timeout"), 0);
  setImmediate(() => console.log("B: immediate (check)"));
});

$ node main.js
A: جُوّه callback بتاع readFile (poll)
B: immediate (check)
C: timeout

A، وبعدين B الـ immediate، وبعدين C الـ timeout. لأننا كنا في مرحلة الـ poll، واللي بعدها على طول check، فالـ immediate كسب. وده مضمون جُوّه أي I O callback. أما في الملف الرئيسي، برة أي I O، الترتيب بينهم مش مضمون، ومش لازم تعتمد عليه. دلوقتي أخطر حاجة في Node كله. timer المفروض يشتغل بعد عشرة milliseconds. وبعده loop sync بتحسب لمدة تانية كاملة، زي ما يكون حد بيشفّر ملف كبير أو بيعمل JSON parse لحاجة ضخمة. نشغّل.

const t0 = Date.now();

setTimeout(() => {
  console.log(`timer كان المفروض بعد 10ms، اشتغل بعد ${Math.round((Date.now() - t0) / 100) * 100}ms`);
}, 10);

// شغل CPU تقيل synchronous: بيمسك الـ event loop
let x = 0;
while (Date.now() - t0 < 1000) x++;
console.log("خلّصنا الحساب");

$ node main.js
خلّصنا الحساب
timer كان المفروض بعد 10ms، اشتغل بعد 1000ms

الـ timer اللي كان المفروض بعد عشرة، اشتغل بعد ألف millisecond. الـ event loop كان ماسك في الحساب، ومش قادر يلف. ولو ده server، كل الـ requests التانية كانت هتستنى التانية دي كلها، حتى الـ health check. وده اسمه blocking the event loop. وفيه درس كامل نقيسه فيه بـ event loop delay، ودرس للـ worker threads اللي بتحل المشكلة دي. ونفس المشكلة ممكن تحصل من غير loop. microtask بتعمل microtask جديدة، مِيّة ألف مرة. والـ timer بـ zero مستني. نشغّل.

let n = 0;
setTimeout(() => console.log("timeout أخيرًا، بعد", n, "microtask"), 0);

function again() {
  n++;
  if (n < 100000) queueMicrotask(again);
}
queueMicrotask(again);

$ node main.js
timeout أخيرًا، بعد 100000 microtask

الـ timer ما اشتغلش غير بعد المِيّة ألف microtask كلهم. لأن Node بيفضّي طابور الـ microtasks للآخر قبل ما يتحرك. لو السلسلة دي ما بتخلصش، الـ timers والـ I O عمرهم ما هيشتغلوا، وده اسمه starvation. ونفس الكلام مع nextTick. التحدي: اتوقّع الترتيب. هلزقلك code فيه تمن حروف، كل واحد في طابور مختلف، منهم async function و await. هتكتب الترتيب اللي متوقعه في array اسمها guess، قبل ما تشغّل. وبعدين تطبع الترتيب الحقيقي، وتقارن. الكومنت فيه القواعد اللي هتحتاجها.

الحل. الـ sync الأول: F، و G، لأن أول جزء في الـ async function sync لحد أول await. بعدين nextTick: D. بعدين الـ microtasks بالترتيب: B، و E، و H اللي بعد الـ await. و C؟ اتعملت جُوّه B، بس nextTick اللي بيتعمل وسط الـ microtasks بيستنى لحد ما طابورهم يفضى. وفي الآخر الـ timer: A. نشغّل.

const order = [];
const log = (x) => order.push(x);

setTimeout(() => log("A"), 0);
Promise.resolve().then(() => {
  log("B");
  process.nextTick(() => log("C"));
});
process.nextTick(() => log("D"));
queueMicrotask(() => log("E"));
log("F");
(async () => {
  log("G");
  await null;
  log("H");
})();


const guess = ["F", "G", "D", "B", "E", "H", "C", "A"];

setTimeout(() => {
  console.log(order.join(" "));
  console.log(guess.join(" ") === order.join(" ") ? "صح" : "راجع الطوابير");
}, 20);

$ node main.js
F G D B E H C A
صح

الترتيب طابق: صح. لو طلعلك ترتيب تاني في محاولتك، رجّع للـ slide بتاعة الأولويات وامشي حرف حرف. الدرس الجاي: الـ streams والـ backpressure، إزاي تتعامل مع ملف أكبر من الـ memory من غير ما الـ server يقع.