اولی درپر، مهندس برجسته کلاه قرمزی

Orran Krieger، Lead/PI Mass Open Cloud (MOC) و Red Hat Collaboratory

ماه آینده در هفدهمین کارگاه آموزشی در مورد موضوعات داغ در سیستم عامل در برتینورو، ایتالیا، جلسه ای در مورد مقاله ای با عنوان "یک انشعاب() در جاده" توسط اندرو باومن (پژوهش مایکروسافت)، جاناتان آپاوو (دانشگاه بوستون)، برگزار خواهد شد. Orran Krieger (دانشگاه بوستون)، و Timothy Roscoe (ETH Zurich.) این مقاله استفاده از fork() را به عنوان یک انتزاع اساسی برای سیستم های عامل، جزئیات مسائل مربوط به fork() در دوران مدرن و همچنین پیشنهاد راه حل های جایگزین را مورد بحث قرار می دهد. ما مقاله را در اینجا در دسترس قرار داده ایم: A fork() in the road (PDF, 528K) این مقاله به سرعت بحث های زیادی را ایجاد کرده است: Hacker News، Twitter، LWN، Reddit، و Lobsters همگی دارای موضوعات بحث و گفتگوی طولانی در مورد نقاط هستند. توسط کاغذ مطرح شده است. ما می خواهیم بحث دیگری در مورد مقاله به اشتراک بگذاریم، این بحث بین Red Hat DE Uli Drepper و Orran Krieger. بحث آنها از قالب خاصی پیروی می کند که از قبل توافق شده بود: اولی یک پاسخ اولیه به روزنامه نوشت، اورران یک ردیه ارائه کرد و در نهایت به اولی فرصت برای رد نهایی داده شد. گفتگوی زیر را دنبال کنید!

پاسخ اولیه Uli

1. fork() واقعاً طراحی نشده است، بیشتر یک جزئیات پیاده سازی تصادفی است
2. پیاده سازی مطابق با تمرین تاریخی و سپس استانداردسازی بعدی مستلزم آن است که بسیاری از بخش های سیستم عامل با پیاده سازی fork() ارتباط داشته باشند.
3. این وابستگی ها و پیوندها اجرای یک سیستم عامل متفاوت از یک سیستم سنتی یونیکس را دشوار می کند و در عین حال سازگاری برنامه را در سطح کد منبع حفظ می کند.
4. نتایج تجربی نشان می دهد که fork() راه غالب برای شروع یک برنامه جدید است
5. شروع یک برنامه جدید از طریق fork() بسته به استفاده از منابع پردازش والد (عمدتاً حافظه) می تواند تاخیر بالایی داشته باشد.
6. با وجود اشکالات، fork() به عنوان طراحی خوب آموزش داده می شود

• بله، fork() خوش فکرترین رابط نیست
• بله، در برخی شرایط که یک برنامه جدید باید شروع شود، مشکلات عمده ای وجود دارد
• اینکه fork() آموزش داده شود یا نه طرح خوبی است که نمی توانم بگویم، برای طولانی ترین زمان فکر می کردم فاقد آن است.

• اختلاط آرگومان های fork() و fork() + exec . اینها مشکلات جداگانه ای هستند اما…
• ... موقعیت های مختلف زمانی که fork() بدون exec مفید است، در بهترین حالت، کمتر نشان داده می شوند
• هیچ جایگزینی واقعی واقعی ارائه نشده است
• تمام استدلال های مربوط به چنگال () نیز در مورد رابط کاربری کلون () لینوکس (و هر آنچه از سیستم عامل های دیگر استفاده می کند) اعمال می شود ، اما این بیان نشده است اما باید در آرگومان ها در نظر گرفته شود (همانطور که در زیر انجام می دهم)
• بخش اعظم استدلال در مورد معنایی استاندارد رابط چنگال () است. من استدلال می کنم که تقریباً هیچ برنامه ای به بیشتر الزامات بستگی ندارد. چرا باید یک سیستم عامل جدید یا سیستم عامل تحقیق محدود باشد؟از رابط های جایگزین فقط با معنایی مناسب استفاده می شود.

• شروع یک برنامه جدید از طریق Fork () + Exec وحشتناک است زیرا تمام/بیشتر الزامات معنایی چنگال () هدر می رود
• کار مورد نیاز برای مقیاس های چنگال () با تعداد صفحات در فضای آدرس والدین ، تعداد توصیف کننده های پرونده و برخی از اشخاص دیگر که می توانند منجر به تأخیر بالا شوند (به عنوان مثال ، فرآیندهای غول پیکر جاوا شروع یک برنامه)
• دلایل زیادی برای استفاده از چنگال () (یا کلون () و غیره) بدون اجرای وجود دارد. لینوکس مدرن دارای فضاهای نام است که می تواند از این طریق استفاده شود ، به طور سنتی رابط Daemon () و غیره با چنگال () اجرا می شوند. و…
• … به طور کلی برنامه های چند فرآیند می توانند و باید با چنگال اجرا شوند (). به اشتراک گذاشتن طرح فضایی آدرس منجر به مزایای اصلی طراحی می شود (و ، نه ، به دلیل عدم وجود ASLR یک مشکل امنیتی اضافی نیست زیرا جایگزین ، موضوعات ، همه دارای یک طرح فضایی آدرس یکسان هستند.
• در حالی که در مورد موضوع ، موضوعات به دلیل سابقه اجرای ، به خوبی یا حتی بیشتر یک نقص طراحی هستند و احتمالاً نمی توان آن را به عنوان یک جایگزین معتبر برای برنامه های چند فرآیند تصور کرد.

• بخشی از فضای آدرس را با کودک به اشتراک بگذارید
• زیر مجموعه ای از توصیف کننده های پرونده و منابع مشابه را از والدین به کودک ارائه دهید
• این کار را بدون تأخیر زیاد انجام دهید

توهین اورران

با تشکر Uli! شما یک نکته خوب را مطرح می کنید ، که اکثر مقاله اساساً در مورد ترکیب Fork+Exec به عنوان مکانیسمی برای ایجاد برنامه های جدید است. به نظر می رسد که ما در مورد مشکلات آن ترکیب کاملاً توافق داریم. من فکر می کنم ما نیز در توافق جدی هستیم که Posix_Spawn باید در هسته اجرا شود و پیشرفته باشد. شما تعدادی از نکات دیگر را مطرح می کنید که ما با آن کاملاً موافق نیستیم. اول ، شما می گویید "به طور کلی برنامه های چند فرآیند می توانند و باید با چنگال () اجرا شوند". این احتمالاً چیزی است که ما در مورد آن توافق نخواهیم کرد. اگر نیاز به انزوا مهم باشد ، پس از آن استفاده از چندین فرآیند به جای موضوعات/رویدادها منطقی است ، با این حال ، من استدلال می کنم که بهتر است چندین فرآیند را با استفاده از Spawn ایجاد کنیم و سپس هرگونه اشتراک مورد نیاز را ایجاد کنیم (به عنوان مثال ، عبور از FDSو ایجاد نقشه های مشترک). حافظه را می توان با استفاده از توضیحات بین فرآیندها ، کپی بر روی نوشتار به اشتراک گذاشت-به اشتراک گذاری حافظه AI-Prori به دلایل مورد بحث مشکل ساز است. به نظر می رسد مجبور کردن برنامه نویس برای صریح جایی که می خواهند به اشتراک بگذارند (به جای اینکه آن را به طور پیش فرض داشته باشند) بسیار کمتر مستعد به نظر می رسد. بله ، این استدلال وجود دارد که مجدداً شروع می شود می تواند قابل توجه باشد ، اما ، مجبور کردن برنامه ها به داشتن استخر تا حدودی بزرگتر از فرآیندهای طولانی مدت ، به نظر می رسد هزینه متوسطی برای آلاینده رابط سیستم عامل های ما با چنگال () با تمام وجود دارد. مشکلات شرکت کننده ای که ما توصیف می کنیم. همانطور که جاناتان فقط به من یادآوری کرد ، گزینه های دیگری نیز وجود دارد که در جامعه تحقیقاتی ایجاد شده است تا روند کار را بدون چنگال تسریع کند () ، اما ... این احتمالاً خارج از محدوده این بحث است. شما اظهار می کنید: "من پیشنهاد نمی کنم که کلون () ایده آل باشد ، اما در اجرای یک دسته کامل از فناوری های جدید ، از اجرای موضوع واقعی گرفته تا ظروف ، به خوبی به ما خدمت کرده است. این یک فریاد دور از این ادعا است که چنگال () از نوآوری جلوگیری می کند ، تحقیقات سیستم عامل است. "موافقت کرد ، این امر از نوآوری جلوگیری نمی کند ، فقط آن را دشوارتر می کند (ما می گوییم "نوآوری را محدود می کند" ، که من موافقم بیش از حد است). بدیهی است که با جامعه عظیم منبع باز لینوکس ، نوآوری اتفاق می افتد. اما هرچه بیشتر موانع را از بین ببریم بهتر است. هربار که به سیستم عامل های خود انتزاعی اضافه می کنیم ، باید در مورد این که اگر یک برنامه/کلون برنامه کاربردی باشد ، فکر کنیم یا تصمیم بگیریم که انتزاع در کودک شکسته شود. من استدلال های مقاله را در مورد چند رشته ای ، DPDK ، بافر سطح برنامه ، شتاب دهنده ها تکرار نمی کنم. همه کار نمی کنند

داشتن انتزاع اساسی سیستم عامل برای ایجاد فرآیندهای جدید که دارای معناشناسی غیر تعریف شده برای یک سری کامل از انتزاع هستند ، اشتباه است. شما می گویید "اگر می توان نشان داد که ما می توانیم یک (مجموعه) رابط برای ساختن یک فرآیند جدید از سطح زمین تحت کنترل کد والدین داشته باشیم ، این واقعاً یک پیشرفت خوب خواهد بود."نشان داده شده است ، چندین بار توسط چندین سیستم عامل تحقیق. نشان داده شده است که مکانیسم هایی که فرآیندهای کودک را از والدین فعال می کنند و می توانند عملکرد بالایی داشته باشند ، ... نگرانی اصلی شما به نظر می رسد "چگونه می توانم به یک برنامه [با امتیازات بالا] که توسط والدین از قطعات ساخته شده است اعتماد کنم؟"من با این نگرانی موافقم. ما استدلال می کنیم که این نگرانی برای چنگال/اعدام اعمال می شود ، جایی که کودک با یک محیط ارثی که توسط والدین ایجاد شده است (و زنجیره والدینی که آن را ایجاد کرده اند) شروع می کند. دیدگاه من/ما (و خاطره کاری که در سیستم عامل های تحقیقاتی گذشته انجام دادیم) نشان می دهد که راه ایجاد یک فرآیند با امتیازات بالا/متفاوت ، ایجاد درخواست برای ایجاد آن فرآیند از طریق سرور/فرآیند دیگر است (اولویت من) یا اگر تخم ریزی در هسته ساخته شده است ، برای استفاده از آن ؛اطمینان از اعتبارسنجی تمام وضعیت روند جدید با دقت. با این حال ، من موافقم ، در حالی که ما سعی کردیم مسیری را برای گزینه های دیگر پیشنهاد کنیم ، مطمئناً (در حالی که به سختی در فضا قرار می گیریم) با این موضوع به هیچ وجه رفتار نکردیم. هدف اساسی ما این است که مشکل را مطرح کرده و به مسیرهای بالقوه اشاره کنیم. در حالی که ممکن است شما موافقت کنید که ترکیب Fork ()/Exec () بد است ، نتیجه گیری مطمئناً توسط اکثر کتاب های درسی به اشتراک گذاشته نمی شود ، و این نکته اصلی مقاله بود.

توهین به Uli

شروع برنامه های چند فرآیند با POSIX_SPAWN () ، داشتن طرح های فضایی یکسان به دلیل ASLR بسیار غیرممکن است. گذشته از داشتن درگیری های محدوده آدرس ممکن حتی برای مناطق صریح مشترک ، داشتن موقعیت های ثابت برای بقیه (از جمله بخش های متن) مفید است زیرا این امکان را می دهد تا خیلی آزادتر از نشانگرها استفاده کنید. گذشته از این ، هنگامی که طرح فضایی آدرس متفاوت باشد ، کاربردی کمتر به احتمال زیاد کار خواهد کرد زیرا معمولاً نشانگرها در بخش داده ها ذخیره می شوند. علاوه بر این ، "(ه) خیلی وقت ما به سیستم عامل های خود انتزاعی اضافه می کنیم ، باید به این فکر کنیم که اگر یک چنگال/کلون های برنامه" واقعاً ضروری نباشد ". ترک (بخشی از) دولت تعریف نشده کاملاً خوب است. ممکن است که بعد از یک چنگال () عملکرد خاصی در دسترس نباشد یا اینکه برنامه هایی با استفاده از عملکرد خاص نمی توانند در وهله اول چنگال () را چنگ بزنند. این کاملاً خوب است ، برنامه نویسان می توانند به آن واکنش نشان دهند. این امر در مورد استفاده هایی مانند DPDK نیز صدق می کند: من شک دارم که کاربر DPDK بحث کند اگر بعد از چنگال () پشته دیگر در دسترس نباشد. پیشنهاد اجرای راه اندازی برنامه با استفاده از خدمات میکرو هسته مانند چیزی نیست که بتوانم جدی بگیرم. لیست خالی از سیستم عامل های میکرو هسته با هدف گسترده ، برای خودش صحبت می کند. به نظر نمی رسد که شما نمی توانستید چیزی را برای نشستن در بالای هسته سیستم عامل موجود ایجاد کنید تا برخی از عملکردها را به سطح UserLevel منتقل کنید. این به سادگی هرگز کار نکرد ، پیچیدگی اجرای (که شما سعی می کنید آن را کاهش دهید!) و الگوی امنیتی به بهترین دانش من ، تمام تلاش های خود را در آهنگ های آنها متوقف کرد. به طور کلی این هدف از سیستم عامل برای توسعه و استقرار کارآمدتر و کارآمدتر از برنامه ها است. این هدف از سیستم عامل نیست که زندگی توسعه دهندگان سیستم عامل و محققان را خوشایندتر کند. مگر اینکه در واقع عملکردی وجود داشته باشد که ضمن حفظ توانایی استفاده از عملکرد چنگال () قابل اجرا باشد ، هیچ توجیهی برای رها کردن رابط وجود ندارد.

ادامه گفتگو