Product SiteDocumentation Site

B.5. فضاء المستخدم

يشير ”فضاء المستخدم user-space“ إلى بيئة تشغيل العمليات العادية (مقارنة بعمليات النواة). لا يعني هذا بالضرورة أن المستخدم يُشَغِّل هذه العمليات لأن النظام القياسي يحوي عادة خدمات عدة تعمل قبل أن يبدأ المستخدم جلسة العمل حتى. تنتمي خدمات النظام لفضاء المستخدم.

B.5.1. عملية

عندما تنهي النواة طور تهيئتها، تبدأ العملية الأولى، init. العملية #1 وحدها نادرًا ما تكون مفيدة بحد ذاتها، ونظم التشغيل المشابهة لنظام يونكس تعمل مع مجموعة كبيرة من العمليات.
أولاً، يمكن للعملية استنساخ نفسها (تعرف هذه العملية بالاشتقاق fork). تخصص النواة مساحة ذاكرة جديدة للعملية، لكن مطابقة للقديمة، وعملية أخرى لاستخدامها. عند هذه اللحظة، الاختلاف الوحيد بين العمليتين هو رقم التعريف pid. تدعى العملية الجديدة بالعملية الابن عادة، والعملية التي لم يتغير رقم تعريفها، بالعملية الأم.
أحيانًا تتابع العملية الابن قيادة حياتها الخاصة مستقلة عن الأم، باستخدام بياناتها الخاصة المنسوخة عن العملية الأم. مع ذلك، تنفذ هذه العملية الابن، في العديد من الحالات برنامجًا آخر. مع بعض الاستثناءات القليلة، تُستَبدل ذاكرتها ببساطة بذاكرة البرنامج الجديد، ويبدأ تنفيذ هذا البرنامج. بالتالي فإن أحد الأعمال الأولى للعملية رقم 1 هو استنساخ نفسها (ما يعني وجود، لفترة زمنية قصيرة جدًا، نسختين فعالتين من العملية init نفسها)، لكن سكربت تهيئة النظام الأول يستبدل العملية الابن بعدها، عادة ما يكون /etc/init.d/rcS. يستنسخ هذا الـسكربت نفسه بدوره، ويشغل عدة برامج أخرى. عند لحظة ما، تبدأ إحدى العمليات من ذرية init واجهة رسومية حتى يسجل المستخدمون دخولهم (التسلسل الحقيقي للأحداث مشروح بمزيد من التفصيل في قسم 9.1, “إقلاع النظام”).
عندما تنهي العملية المهمة التي بدأت لأجلها، تنتهي العملية. بعدها تستعيد النواة الذاكرة المخصصة لهذه العملية، وتقطع عنها شرائح التشغيل الزمنية. يتم إعلام العملية الأم عن انتهاء عمليتها الابن، ما يسمح لعملية ما أن تنتظر إنهاء مهمة فوضت أحد أبنائها بها. هذا السلوك واضح للعين المجردة في مفسرات سطر الأوامر (تعرف باسم الأصداف shells). عند كتابة أمر في الصَدَفَة، لا تعود إشارة الإدخال قبل انتهاء تنفيذ الأمر. تسمح معظم الأصداف بتشغيل الأوامر في الخلفية، يكون ذلك بسهولة بإضافة & إلى نهاية الأمر. بعدها تظهر إشارة الإدخال مجددًا مباشرة، وهذا قد يسبب مشاكل إذا كان الأمر يحتاج لإظهار بيانات خاصة به.

B.5.2. الجن

”الجني daemon“ هو عملية تُشغِّلها متتالية الإقلاع آلياً. يبقى نشطاً (في الخلفية) لتنفيذ مهام صيانة أو تقديم خدمات للعمليات الأخرى. هذه ”المهمة في الخلفية“ عشوائية في الحقيقة، ولا تقابل أي شيء محدد من وجهة نظر النظام. هي مجرد عمليات، شبيهة بالعمليات الأخرى تماماً، التي تعمل بدورها عندما تحين حصتها من الوقت. هذا التمييز موجود في لغة البشر فقط: أية عملية تعمل بدون أي تفاعل مع المستخدم (على الأخص، بدون واجهة رسومية) يقال أنها تعمل ”في الخلفية“ أو أنها ”جني“.
هناك شرح مفصل لمجموعة من الجن أمثال هؤلاء في فصل 9, خدمات يونكس.

B.5.3. التواصل بين العمليات

إن العملية المعزولة، سواء كانت خدمة أو تطبيقًا تفاعليًا، نادراً ما تكون مفيدة بحد ذاتها، وهو السبب وراء وجود العديد من أساليب التواصل بين العمليات المنفصلة، سواء لتبادل البيانات أو لتتحكم واحدتها بالأخرى. المصطلح العام للتعبير عن هذا المفهوم هو التواصل بين العمليات inter-process communication، أو IPC اختصاراً.
أبسط نظام IPC هو استخدام الملفات. تكتب العملية التي ترغب بإرسال البيانات بياناتها في ملف (له اسم معروف مسبقًا)، في حين تحتاج العملية المتلقية إلى فتح الملف وقراءة محتوياته فقط.
في الحالات التي لا يرغب فيها المرء بتخزين البيانات على القرص، يمكنه استخدام أنبوب، وهو ببساطة عنصر له نهايتان؛ البايتات المكتوبة في إحداهما، تكون مقروءة عند النهاية الأخرى. إذا تَحكَّمَت بالنهايتين عمليتين منفصلتين، يصبح الأنبوب بمثابة قناة تواصل بين العمليات بسيطة وسهلة الاستعمال. يمكن تصنيف الأنابيب في زمرتين: الأنابيب المسمّاة، والأنابيب المجهولة. يُمثَّل الأنبوب المسمى بمدخلة في نظام الملفات (مع أن البيانات المرسلة لا تُخزَّن هناك)، بحيث يمكن لكلا العمليتين فتحه بشكل مستقل إذا كان موقع الأنبوب المسمى معروفًا من قبل. في الحالات التي تكون فيها العمليات التي تتواصل فيما بينها مرتبطة ببعضها (مثلاً، عملية أم مع ابنها)، يمكن للعملية الأم أيضًا إنشاء أنبوب مجهول قبل الاشتقاق، وسيرثه الابن. ستتمكن كلا العمليتان عندئذ من تبدل البيانات فيما بينهما باستخدام الأنبوب دون الحاجة لنظام الملفات.
لا تستخدم جميع الاتصالات بين العمليات لنقل البيانات بينها مع ذلك. في العديد من الحالات، المعلومات التي نحتاج إرسالها رسائل تحكم مثل ”أوقف التنفيذ مؤقتاً“ أو ”تابع التنفيذ“. يقدم يونكس (ولينكس) آلية تُعرَف باسم الإشارات signals، تستطيع العملية من خلالها إرسال إشارة ببساطة (تختارها من قائمة ثابتة من بين عدة عشرات من الإشارات المعرفة مسبقاً) إلى عملية أخرى. المتطلب الوحيد هو معرفة pid العملية الهدف.
هناك آليات أخرى للاتصالات الأكثر تعقيدًا، تسمح للعملية بالسماح لفتح الوصول إلى الذاكرة المخصصة لها، أو مشاركة جزء منها مع العمليات الأخرى. عندئذ يمكن استخدام الذاكرة المشتركة بينهم لنقل البيانات عبرها.
أخيرًا، يمكن أن تساعد الاتصالات الشبكية بالتواصل بين العمليات؛ يمكن أن توجد هذه العمليات على حواسيب مختلفة، وقد تبعد عن بعضها آلاف الكيلومترات.
من العادي جداً لأي نظام نموذجي مشابه لنظام يونكس أن يستخدم جميع هذه الآليات بدرجات متفاوتة.

B.5.4. المكتبات

تلعب مكتبات الدوال دوراً حيويًا في نظم التشغيل المشابه لنظام يونكس. ليست هذه المكتبات برامج تامة، نظرًا لعدم إمكانية تنفيذها منفردة، لكنها مجموعة من فتات الكود التي يمكن للبرامج القياسية استخدامه. من المكتبات الشائعة، نذكر ما يلي:
  • مكتبة C القياسية (glibc)، التي تحوي الوظائف الأساسية مثل دوال فتح الملفات أو الاتصالات الشبكية، وغيرها مما يسهل التفاعل مع النواة؛
  • المكتبات الرسومية، Gtk+‎ وQt، تسمح للعديد من البرامج بإعادة استخدام العناصر الرسومية التي توفرها؛
  • مكتبة libpng، التي تسمح بتحميل، وتفسير وحفظ الصور بصيغة PNG.
بفضل هذه المكتبات، تستطيع البرامج إعادة استخدام الكود. ونتيجة لذلك يصبح تطوير هذه البرامج أبسط، خصوصا عندما تستخدم عدة تطبيقات الدوال نفسها. بما أن تطويرالمكتبات يتم بأيدي أشخاص مختلفين عادة، فإن التطوير الكلي للنظام أقرب إلى فلسفة يونكس التاريخية.
بالإضافة إلى ذلك، غالباً ما يُشَار إلى هذه المكتبات على أنها ”مكتبات مشتركة“، لأن النواة تستطيع تحميلها إلى الذاكرة مرة واحدة فقط، حتى لو كانت عدة عمليات تستخدم المكتبة نفسها في الوقت ذاته. يسمح هذا بتوفير الذاكرة، مقارنة مع الحالة (النظرية) النقيضة لها حيث يتم تحميل كود المكتبة بعدد العمليات التي تستخدمها.