Stav si může držet i couroutina. Koukal jsem na ten Phoenix framework. Je to pěkné, ale nevidím tam nic, k čemu by byla nutná vlákna. Ještě se na to podívám později.
Jde především o 1. jednoduchost řešení 2. o paralelizovatelnost "zadarmo" (bez toho, aby se o ni musel programátor nějak explicitně starat).
Načtu stránku - dojde k autentizaci a inicializaci stavu (načtení nebo vytvoření session). Každá událost na webu se pak odešle na backend (tomu procesu) a ten modifukuje stav. Zavření stránky = ztráta spojení = zrušení procesu, příp. uložení stavu.
Pokud mám green threads, můžu to celé psát tak, jako bych měl jednovláknovou aplikaci, která obsluhuje právě jednoho klienta a nic jiného ji nezajímá. Narozdíl od té výš zmíněné obezličky s N interpretery (kde jich navíc typicky nemůžu mít tolik, kolik mám klientů) ale navíc můžu snadno posílat události mezi takovými procesy. Tady v tom Phoenixu je to pubsub - klienta zajímají např. zprávy v chatové místnosti, tak každou novou zprávu odešlu na daný kanál a pubsub ji automaticky doručí všem procesům a ty procesy pak informují svého klienta. Protože těch procesů mám typicky víc než jader, škáluje mi to prakticky lineárně a přitom vůbec neřeším nějaké korutiny odskoky sem a tam, zamražení stavu a jeho zpětné načtení až na něj přijde řada, nemusím přepínat kontext jenom v pevně daných okamžicích, ale prakticky (z pohledu programátora) kdykoli atd. atd. atd.
Dost těžko se to vysvětluje, je potřeba si s tím tak půl roku hrát, aby si člověk uvědomil, v čem všem se to vyplatí a jakými všemi způsoby to usnadňuje práci. Nedělám si sebemenší naději, že bych to uměl nějak nevyvratitelně dokázat. Zkus a uvidíš, třeba se mýlím.
Nicméně o stavu jsem nic neříkal. Představuju si eventloop (kód pak je nějaká šílenost s vnořenými callbacky), přičemž volání knihovny se rozprostřou na více jader. High-level kód pak může být sekvenční a ostatní jádra využije jen kód knihovny. Záleží samozřejmě na tom, co píšu. Alternativně by šlo mít jen funkcionální datové struktury a tam, kde to nejde, na těch pár místech použít zámky. Pak by ani ten high-level kód nemusel být sekvenční.
No jo, ale takhle by to právě mohlo fungovat (jestli jsem tě pochopil správně) jenom pokud by 1. ty operace byly vůbec principielně paralelizovatelné 2. pokud by ten "podvozek" (runtime jazyka nebo knihovna) uměl poznat, že to může paralelizovat.
Jasně, pokud ten event bude "k tomuhle poli tisíce hodnot připočti jedničku", tak to paralelizovat jde. Ale to není úplně typická operace na webovém backendu, notabene napsaném v OOP jazyce, navíc tak nevyzpytatelném/flexibilním [nehodící se škrtni
] jako je Python...
Zobrazit příspěvky
Ten tolikrát vychvalovaný Spring v o několik řádů rychlejší Javě je v něm totiž například pomalejší než flask s Pythonem. A to se bavíme o reálných problémech webového backendu
