إصدار Node.js 10.5: تعدد مؤشرات خارج الصندوق

في الأسبوع الماضي ، تم إصدار الإصدار 10.5.0 من Node.js ، والذي يحتوي على ابتكار من الصعب المبالغة في أهميته - دعم تعدد المواضيع في شكل وحدة worker_threads . سأقوم بإجراء الحجز على الفور. واجهة برمجة التطبيقات في مرحلة تجريبية وبالتالي قد تتغير ، ولكن يمكنك الآن ترك انطباع أول والحصول على فكرة عن المبادئ والتقنيات المنصوص عليها في أساسها. وإذا كانت لديك رغبة ، فشارك في إنهاء الواجهة أو كتابة التعليمات البرمجية أو إصلاح الأخطاء (قائمة المشاكل ).

قصة المظهر

طوال حياة Node.js ، كانت الطريقة الوحيدة لموازاة الحوسبة هي بدء عملية جديدة ، على سبيل المثال ، باستخدام وحدة الكتلة. لأسباب عديدة ، لا يناسب هذا النهج المطورين ، على وجه الخصوص لأنه يؤدي إلى التحميل المتكرر للرمز القابل للتنفيذ لـ Node.js مع جميع الوحدات المدمجة في ذاكرة الكمبيوتر ، وهي طريقة غير فعالة لإنفاق الموارد.

ومع ذلك ، فإن مناقشة تنفيذ تعدد سلاسل الرسائل في Node.js استندت دائمًا إلى تعقيد V8 وعدد كبير من المجهول: كيفية توصيل الوحدات الأصلية ، ومشاركة الذاكرة ، والتواصل بين الخيوط والمزيد. وبينما كان المطورون يبحثون عن أي جانب للتعامل مع الموضوع على الويب ، تم تنفيذ Worker API بنجاح ، والذي أصبح بمثابة إرشادات في المراحل الأولية. بدأ التطوير مع addaleax وتم الاستيلاء عليه من قبل المجتمع.

تم تنفيذ العمل النشط خلال العام ، حيث تم تحديد متطلبات التصميم واكتسبت API ميزات خاصة بها خاصة بـ Node.js ، وكانت الوحدة نفسها تسمى worker_threads. فيما يلي ، سأصف بإيجاز جداول العمال - بشكل عام ، ومن أجل دراسة تفصيلية ، أنصحك بزيارة صفحة الوثائق الرسمية .

الوصف

كما ذكر أعلاه ، فإن الهدف من هذا التطوير هو تحسين الإنتاجية من خلال توزيع الحمل عبر سلاسل عمليات منفصلة في نفس العملية ، بدلاً من بدء عدة عمليات. لذلك ، ستدعم مؤشرات الترابط اتصال جميع الوحدات المتاحة للعملية الرئيسية (حاليًا ، الوحدات الأصلية غير مدعومة).

كما هو الحال في Worker API ، يتم تنفيذ التفاعل بين التدفق الرئيسي والتابع عن طريق نقل الكائنات القابلة للتحويل عبر postMessage ، والتي تتجنب مشاكل الوصول المتزامن ، على الرغم من أنها تتطلب وصولًا إضافيًا للذاكرة لنسخ البيانات. في هذه الحالة ، تحتفظ عناصر مثل SharedArrayBuffer بسلوكها ولا تسبب إعادة تخصيص.

تم أخذ MessageChannel و MessagePort من WebAPI ، مما يسمح لك بإنشاء قنوات مراسلة معزولة ونقلها بين سلاسل الرسائل.

من أجل تجربة worker_threads بشكل عملي ، عند بدء العملية ، يجب تحديد علامة خاصة:

node --experimental-worker main.js 

مثال

نظرًا لأن واجهة برمجة التطبيقات قد تستمر في التغيير ، فلن أصفها ، ولكن سأعطي مثالًا لتبادل الرسائل بين سلاسل المحادثات الرئيسية والتابعة ، حيث يُبلغ مؤشر الترابط الفرعي عن معرف thread الخاص به من خلال MessagePort ويخرج.

التيار الرئيسي

رمز المثال لمؤشر الترابط الرئيسي:

 // main.js const {Worker} = require('worker_threads'); const worker = new Worker(__dirname + '/worker.js'); worker.on('online', () => { console.log('Worker ready'); }); worker.on('message', (msg) => { console.log('Worker message:', msg); }); worker.on('error', (err) => { console.error('Worker error:', err); }); worker.on('exit', (code) => { console.log('Worker exit code:', code); }); 

تيار الطفل

يعيش مؤشر الترابط الفرعي حتى تكون حلقة الأحداث الخاصة به فارغة. وهكذا ، فور تنفيذ الكود من worker.js سيتم إغلاق الخيط تلقائيًا. للتواصل مع أحد الوالدين ، يتم استخدام الأصل المنفذ:

 // worker.js const {threadId, parentPort} = require('worker_threads'); parentPort.postMessage(`Hello from thread #${threadId}.`); // Exit happens here 

في سلسلة العمليات الفرعية ، يتم تجاوز كائن العملية ، ويختلف سلوكه قليلاً عن سلوك العملية في سلسلة العمليات الرئيسية. على وجه الخصوص ، لا توجد طريقة للرد على إشارات SIGNINT ، وتغيير قيم process.env ، واستدعاء process.exit سيوقف العامل فقط ، ولكن ليس العملية بأكملها.

الخلاصة

يبسط العمال إلى حد كبير إنشاء التطبيقات التي تتطلب التفاعل بين أقسام الكود القابلة للتنفيذ الموازية ، وهو أمر مهم بشكل خاص ، يجعل الاتصال والتحكم في التدفق أكثر الطرق وضوحًا. وسيسمح أيضًا بتجنب القيود الخاصة بالنظام الأساسي بسبب الاختلاف بين Windows و Unix. أنا متأكد من أن الفرص التي ستفتح ستجذب مطورين جدد لم يختاروا Node.js. في غضون ذلك ، استمر في مراقبة التغييرات والتواصل مع عملية تطوير واجهة برمجة التطبيقات في المستودع .

المراجع

• وثائق Worker_threads .
• تصوير بول سميث.