نقاش في نواة لينكس: تجاوز fork() + exec() عبر قوالب الإطلاق

منذ الأيام الأولى ليونكس، تعتمد عملية إنشاء العمليات على استدعاءين للنظام: fork() الذي ينشئ عملية ابنة كنسخة من الأب، وexec() الذي يشغّل برنامجًا جديدًا بدلًا من الحالي. في نواة لينكس يُعرفان أكثر باسم clone() وexecve()، لكن النموذج لم يتغير. وقد نوقش في قائمة بريد النواة اقتراح حديث من لي تشن لإضافة "قوالب الإطلاق" (spawn templates) إلى النواة؛ ولن يُقبل بصيغته الحالية، لكنه قد يشير إلى بدائية جديدة لإنشاء العمليات.

كلفة fork() متبوعًا بـ exec()

يُعدّ fork() استدعاءً مكلفًا نسبيًا: إذ على النواة أن تنسخ للعملية الابنة كامل حالة العملية بما فيها الذاكرة. وقد أُجريت تحسينات كثيرة على مرّ السنين، لكن fork يبقى عملية مكلفة جوهريًا — لا سيما أن النمط الشائع يتبعها فورًا بـ exec() الذي يهدر الذاكرة التي نُسخت بعناية. كان vfork() محاولة مبكرة لتحسين هذه الحالة تحديدًا، لكن التسلسل لا يزال أغلى مما ينبغي.

قوالب الإطلاق والتحضير المخزَّن

تستهدف مجموعة الترقيعات التي أعدّها تشن التطبيقات التي تُشغّل الملف التنفيذي نفسه مرارًا، مثل برنامج يستدعي Git مرارًا وتكرارًا للحصول على معلومات عن مستودع. ويمكن لمثل هذا التطبيق إنشاء قالب عبر استدعاء النظام الجديد spawn_template_create() الذي يعيد واصف ملف للملف التنفيذي، ويُحدَّد الملف إما بواصف (execfd) أو بمسار مطلق (filename)، لا بالاثنين معًا. وتفتح النواة الملف وتخزّن معلومات تتيح تشغيله بسرعة أكبر لاحقًا.

تُوصَف كل عملية إطلاق ببنية spawn_template_spawn_args: يشير argv إلى قائمة الوسائط، وenvp إلى البيئة، وactions إلى مصفوفة من مدخلات spawn_template_action التي تتناول واصفات الملفات ومعالجة الإشارات. فإغلاق الواصف الرابع في العملية الابنة، مثلًا، يُعبَّر عنه بإجراء من النوع SPAWN_TEMPLATE_ACTION_CLOSE مع ضبط fd على أربعة. ثم تُشغَّل العملية عبر spawn_template_spawn()، الذي يسلك داخليًا مسار fork()/exec() المعتاد ويحفظ كل الفحوص؛ والمعلومات المخزَّنة في القالب هي ما يمنح السرعة. وتُظهر نتائج القياس في الرسالة المرافقة تحسّنًا بنحو 2%.

المراجعون: المشكلة في جزء fork()

كتب ماتيوش غوزيك أكثر المراجعات تفصيلًا: "إن أسلوب fork + exec بأكمله سيئ ويجب إحالته إلى التقاعد". وأشار إلى أن مجموعة الترقيعات لا تمسّ الجزء المتعلق بـ fork()، مع أن معظم الكلفة هناك، ورأى أن "إنشاء عملية نظيفة هو الطريق الصحيح". ورحّب كريستيان براونر بالهدف — "فكرة وجود واجهة builder لـ exec ليست جنونية إلى هذا الحد" — لكنه اقترح بناء الواجهة الجديدة على تجريد pidfd القائم: خيار جديد في pidfd_open() ينشئ عملية فارغة، ثم تُهيّئ سلسلة من استدعاءات pidfd_config() الجديدة بيئتها والصورة التي ستُشغَّل، على غرار fsconfig().

من أهداف براونر الرئيسية دعم تنفيذ posix_spawn() في فضاء المستخدم. وتناسب posix_spawn() استبدال نمط fork()/exec() جيدًا، ومن المرجّح أن يرحّب المطوّرون بتنفيذ أصيل لا يخفي fork() وexec() تحت الغطاء كما يفعل التنفيذ الحالي. ووافق تشن على أن الواجهة التي رسمها براونر تبدو أفضل، وقال إن العمل المستقبلي سيسير في هذا الاتجاه. أي لن تدخل قوالب الإطلاق إلى نواة لينكس — لكن لينكس قد تحصل أخيرًا على تنفيذ سليم لـ posix_spawn().