Քննարկում Linux-ի միջուկում՝ fork() + exec()-ի փոխարինումը spawn templates-ով

Unix-ի վաղ օրերից ի վեր պրոցեսների ստեղծումը հենվում է երկու համակարգային կանչի վրա՝ fork(), որը ծնողի պատճենն է դարձնում զավակ պրոցեսը, և exec(), որը ընթացիկ պրոցեսի տեղում նոր ծրագիր է գործարկում։ Linux-ի միջուկում դրանք ավելի հայտնի են որպես clone() և execve(), սակայն մոդելը չի փոխվել։ Li Chen-ի առաջարկը՝ միջուկին «spawn templates» ավելացնելու մասին, քննարկվել է միջուկի փոստային ցուցակում. այն ներկայիս տեսքով չի ընդունվի, բայց կարող է ուղի հարթել պրոցեսի ստեղծման նոր պրիմիտիվի համար։

Ինչու fork() + exec() թանկ է

fork()-ը համեմատաբար թանկ համակարգային կանչ է. միջուկը զավակ պրոցեսի համար պետք է պատճենի ամբողջ վիճակը՝ ներառյալ հիշողությունը։ Տարիներով բազմաթիվ օպտիմիզացիաներ են արվել, բայց fork-ը մնում է սկզբունքորեն ծախսատար, առավել ևս որ սովորական օրինաչափությամբ անմիջապես հաջորդում է exec(), որը դեն է նետում նոր պատճենված հիշողությունը։ vfork()-ը վաղ փորձ էր՝ օպտիմիզացնելու հենց այդ դեպքը, սակայն հաջորդականությունը դեռ ավելի թանկ է, քան կարող էր լինել։

Կաղապարներ և քեշավորված նախապատրաստում

Chen-ի patch-ների հավաքածուն ուղղված է ծրագրերին, որոնք բազմիցս գործարկում են նույն կատարվող ֆայլը՝ օրինակ՝ պահոցի մասին տեղեկություն ստանալու համար կրկին ու կրկին Git կանչող ծրագիրը։ Նման ծրագիրը կարող է կաղապար ստեղծել նոր spawn_template_create() կանչով, որը վերադարձնում է կատարվող ֆայլի դեսկրիպտորը. ֆայլը նշվում է կամ դեսկրիպտորով (execfd), կամ բացարձակ ուղով (filename), բայց ոչ երկուսով միաժամանակ։ Միջուկը բացում է ֆայլը և քեշավորում տեղեկություն, որը թույլ է տալիս այն հետագայում ավելի արագ գործարկել։

Ամեն գործարկում նկարագրվում է spawn_template_spawn_args կառուցվածքով. argv-ն ցույց է տալիս արգումենտների ցանկին, envp-ն՝ միջավայրին, իսկ actions-ը՝ դեսկրիպտորներն ու ազդանշանների մշակումը կարգավորող spawn_template_action գրառումների զանգվածին։ Ապա պրոցեսը գործարկվում է spawn_template_spawn()-ով, որը ներսում գնում է սովորական fork()/exec() ուղուն մոտ և պահպանում բոլոր ստուգումները. արագությունը տալիս է քեշավորված տեղեկությունը։ Ուղեկցող նամակի benchmark-ի արդյունքները ցույց են տալիս մոտ 2% բարելավում։

Գրախոսները՝ խնդիրը fork()-ի մասում է

Ամենամանրամասն գրախոսությունը գրել է Mateusz Guzik-ը՝ «fork + exec ամբողջ իդիոմը սարսափելի է և պետք է դուրս գա գործածությունից»։ Նա նշել է, որ patch-ները չեն շոշափում խնդրի fork()-ի կեսը, թեև ծախսի հիմնական մասը հենց այնտեղ է, և որ «մաքուր պրոցես ստեղծելն է ճիշտ ուղին»։ Christian Brauner-ը դրական գնահատեց նպատակը՝ «exec-ի համար builder API-ի գաղափարն այդքան էլ խենթ չէ», սակայն առաջարկեց նոր ինտերֆեյսը կառուցել գոյություն ունեցող pidfd աբստրակցիայի վրա. pidfd_open()-ի նոր տարբերակը կստեղծեր դատարկ պրոցես, իսկ նոր pidfd_config() կանչերի շարքը կկարգավորեր նրա միջավայրն ու գործարկվող պատկերը՝ fsconfig()-ի նման։

Brauner-ի առանցքային նպատակը posix_spawn()-ի՝ օգտատիրոջ տարածքում իրականացման աջակցությունն է։ posix_spawn()-ը լավ է համապատասխանում fork()/exec() օրինաչափությանը փոխարինելու համար, և ծրագրավորողները կողջունեն բնիկ իրականացում, որը fork()-ն ու exec()-ը չի թաքցնում։ Chen-ը համաձայնեց, որ Brauner-ի ուրվագծած API-ն ավելի լավն է, և ասաց, որ ապագա աշխատանքը կգնա այդ ուղղությամբ։ Այսպիսով՝ spawn templates միջուկ չեն մտնի, բայց Linux-ը կարող է վերջապես ստանալ posix_spawn()-ի պատշաճ իրականացում։