Linux-ის ბირთვში დებატები: fork() + exec()-ის ჩანაცვლება spawn templates-ით

Unix-ის დასაწყისიდან მოყოლებული, პროცესების შექმნა ორ სისტემურ გამოძახებას ეყრდნობა: fork(), რომელიც მოძახებული პროცესის ასლს ქმნის, და exec(), რომელიც ამ ასლში ახალ პროგრამას უშვებს. Linux-ის ბირთვში მათ clone() და execve() ეძახიან, თუმცა მოდელი უცვლელია. Li Chen-ის წინადადება „spawn templates“-ის დამატების შესახებ ბირთვის სიაში განიხილეს; ის ამ ფორმით არ მიიღება, მაგრამ შესაძლოა გზა გახსნას პროცესების შექმნის ახალი პრიმიტივისკენ.

რატომ არის fork() + exec() ძვირი

fork() შედარებით ძვირი გამოძახებაა: ბირთვმა შვილობილი პროცესისთვის მთელი მდგომარეობა, მეხსიერების ჩათვლით, უნდა დააკოპიროს. წლების ოპტიმიზაციების მიუხედავად, fork ფუნდამენტურად ძვირი რჩება — მით უფრო, რომ მას თითქმის ყოველთვის exec() მოსდევს, რომელიც ახლად დაკოპირებულ მეხსიერებას აღარ იყენებს. vfork() სწორედ ამ სცენარისთვის შეიქმნა, მაგრამ თანმიმდევრობა მაინც უფრო ძვირია, ვიდრე შეიძლებოდა.

შაბლონები: მომზადების ხარჯის დაზოგვა

Chen-ის პაჩები იმ პროგრამებს მიმართავს, რომლებიც ერთსა და იმავე შესრულებად ფაილს არაერთხელ უშვებენ — მაგალითად, რეპოზიტორიის შესამოწმებლად Git-ს დროდადრო იძახებს. აპლიკაციას შეუძლია შაბლონი შექმნას ახალი spawn_template_create() გამოძახებით, რომელიც შესრულებადი ფაილის დესკრიპტორს აბრუნებს. ფაილი მითითებული უნდა იყოს ან დესკრიპტორით (execfd), ან აბსოლუტური გზით (filename) — ორივე ერთდროულად დაუშვებელია. ბირთვი ფაილს ხსნის და ინახავს ინფორმაციას, რომელიც შემდგომ გაშვებებს აჩქარებს.

ყოველი გაშვება spawn_template_spawn_args სტრუქტურით აღიწერება: argv არგუმენტების სიაზე მიუთითებს, envp გარემოზე, actions — დესკრიპტორებისა და სიგნალების მართვის spawn_template_action ჩანაწერების მასივზე. მაგალითად, შვილობილ პროცესში მეოთხე დესკრიპტორის დახურვა SPAWN_TEMPLATE_ACTION_CLOSE ტიპის ოპერაციით გამოიხატება. შემდეგ პროცესი spawn_template_spawn()-ით ეშვება, რომელიც შიგნით ჩვეულებრივ fork()/exec() გზას მიჰყვება და ყველა შემოწმებას ინარჩუნებს; სისწრაფეს ქეშირებული ინფორმაცია იძლევა. საფარ წერილის ბენჩმარკები დაახლოებით 2%-იან გაუმჯობესებას აჩვენებს.

რეცენზენტები: პრობლემა fork()-ის ნაწილშია

ყველაზე დეტალური რეცენზია Mateusz Guzik-მა დაწერა: „მთელი fork + exec იდიომა საშინელია და უნდა გავიდეს ხმარებიდან“. მისი აზრით, პაჩები პრობლემის fork()-ის ნახევარს არ ეხება, სწორედ იქ არის ხარჯის ძირითადი ნაწილი, ამიტომ „სუფთა პროცესის შექმნაა სწორი გზა“. Christian Brauner მიზანს დადებითად შეხვდა — „exec-ისთვის builder API-ის იდეა არც ისე გიჟურია“ — თუმცა შესთავაზა, რომ ინტერფეისი არსებულ pidfd აბსტრაქციაზე აშენდეს: pidfd_open()-ის ოფცია ცარიელ პროცესს შექმნიდა, pidfd_config() გამოძახებების სერია კი მას fsconfig()-ის მსგავსად დააკონფიგურირებდა.

Brauner-ის მთავარი მიზანი posix_spawn()-ის მომხმარებლის სივრცეში დანერგვის მხარდაჭერაა. posix_spawn() კარგად ერგება fork()/exec() ნიმუშის ჩასანაცვლებლად და დეველოპერები მიესალმებიან ნატიურ იმპლემენტაციას, რომელიც fork()-სა და exec()-ს შიგნით აღარ მალავს. Chen დაეთანხმა, რომ Brauner-ის მონახაზი უკეთესია და მომავალი მუშაობა ამ მიმართულებით წავა. შაბლონები ბირთვში ამ სახით არ მოხვდება, მაგრამ Linux შესაძლოა სათანადო posix_spawn() იმპლემენტაციით აღიჭურვოს.