Zig 0.16.0 iznāca 14. aprīlī, un tas maina veidu, kā programma veic ievadi un izvadi. Async un await atslēgvārdu vairs nav. To vietā ir jauns tips std.Io, ko funkcija saņem kā parastu argumentu — tieši tāpat, kā tā jau saņem atmiņas piešķīrēju (allocator). Kurš I/O dzinējs strādā aiz šī parametra, izlemj tas, kas funkciju izsauc, nevis pati funkcija.
Šis lēmums risina problēmu, ko izstrādātāji sauc par funkciju krāsošanu (function coloring): valodās ar async/await sinhronas un asinhronas funkcijas ir divas atsevišķas kategorijas, un async kods var izsaukt tikai citu async kodu. Rezultātā bibliotēkām bieži jāraksta divas gandrīz vienādas versijas. Zig autors Andrew Kelley savā aprakstā paskaidro, ka viena un tā pati funkcija tagad strādā ar jebkuru dzinēju, jo atšķirība slēpjas parametrā, nevis funkcijas tipā.
Io darbojas kā piešķīrējs
std.Io implementācijas iestatīšana ir ļoti līdzīga piešķīrēja iestatīšanai. To parasti izdara vienu reizi, main() funkcijā, un tad instanci padod cauri visai lietotnei. — Andrew Kelley
Praksē tas nozīmē, ka main() izvēlas konkrētu I/O dzinēju un padod to tālāk. Funkcija, kas grib palaist darbu fonā, izsauc io.async(funkcija, args) un saņem Future. Rezultātu paņem ar future.await(io), bet darbu var pārtraukt ar future.cancel(io). Kelley uzsver, ka atcelšana nav malā atstāta iespēja, bet centrālā daļa: bez tās asinhrons kods noplūdina resursus, kad kaut kas aiziet greizi.
Kelley arī nošķir divus jēdzienus, ko async/await valodas parasti sajauc. io.async() tikai atdala izsaukšanu no rezultāta saņemšanas — vai tas tiešām notiek paralēli, atkarīgs no dzinēja. Ja kodam paralēlisms ir obligāts, tas izsauc io.concurrent(), kas atgriež kļūdu ConcurrencyUnavailable, ja dzinējs to nespēj. Parastais try, return un defer kods paliek nemainīgs.
Vairāki dzinēji aiz viena tipa
0.16.0 nāk ar vairākām std.Io implementācijām atšķirīgā gatavības pakāpē. Io.Threaded balstās uz pavedienu pūlu, ir pilnībā aprakstīts un pārbaudīts, un strādā gan -fsingle-threaded, gan daudzpavedienu režīmā. Io.Evented ir eksperimentāls M:N pavedienu modelis ar steka pārslēgšanu. Tam pievienoti vairāki iestrādes prototipi: Io.Uring Linux io_uring saskarnei (pagaidām bez tīkla darba un kļūdu apstrādes), Io.Kqueue macOS un Io.Dispatch virs Grand Central Dispatch. Ir arī Io.failing, kas simulē vidi, kur neviena I/O operācija nav pieejama — noderīgs testiem.
Virs šiem dzinējiem stāv trīs abstrakcijas dažāda līmeņa darbam: Future vienam uzdevumam, Group daudzu neatkarīgu uzdevumu pārvaldīšanai un Batch zemāka līmeņa operācijām. Atcelšana ir iebūvēta visos trijos.
Kas jau notika 0.15.1 — Writergate
Pāreja uz jauno I/O sākās jau iepriekšējā laidienā. Zig 0.15.1 novecoja visus vecos std.io lasītājus un rakstītājus par labu std.Io.Reader un std.Io.Writer. Jaunie tipi vairs nav generic — tie ir parastas struktūras, kas glabā gan vtable rādītāju, gan buferi. Kopiena šo lūzumu iesauca par Writergate, jo tas salauza gandrīz katru programmu, kas kaut ko izvadīja. Zig komanda laidiena piezīmēs raksta, ka 0.16.0 migrācija ir vieglāka nekā tā: parasti pietiek pievienot io parametru, piemēram, file.close() kļūst par file.close(io).
Cik liels ir laidiens
Aiz 0.16.0 stāv astoņi mēneši darba, 1183 revīzijas un 244 dažādi līdzautori, liecina oficiālais paziņojums. Otra laidiena lielā tēma līdzās I/O ir aarch64 pašmāju kompilatora aizmugure. Zig joprojām nav sasniedzis 1.0, tāpēc katrs šāds solis nes lūzumus, un projekti, kas atjaunojas no 0.14 vai 0.15, ilgstoši dzīvo migrācijas dokumentu pavadībā.
Vai pieeja nostrādās plašā mērogā, izšķirsies pie tīkla slodzes. Io.Threaded ir gatavs ražošanai, bet event-driven dzinēji, kas dod io_uring un GCD sniegumu, joprojām ir prototipi bez pilnas tīkla atbalsta. Tieši tur async modeļi parasti vai nu pierāda sevi, vai grūst.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.