To by se u normalniho stavoveho stroje s await async nemelo stat, protoze tam bezi jenom jeden thread.
Pokud pisete komponentu, kde vam chodi paralelne requesty, tak mate zparalelizovane uz ty requesty. Nepotrebujete paralelizovat i ukoly v ramci jednotlivych requestu, to je nesmysl.
Protoze k tomu abyste z toho opravdu dokazal tezit, tak potrebujete mit drtivou vetsinu metod await async - a proto nemuzete vyrabet novy thread pokade kdyz se vola nejaka metoda.
Neber si to osobně, ale tohle je dost odstrašující příklad přístupu k asynchronnímu programování.
1. chci používat jazyk s mutabilními strukturami (navíc OOP!)
2. async/paralelizaci si představuju tak, že všude možně prsknu async a await
3. očekávám, že to po mně nebude nic chtít, protože to bude "jakože běžet v jednom vlákně"
4. díky tomu, že mám sem tam ten async a await, to bude automagicky škálovat
Prvně by asi nebylo od věci si uvědomit, že
1. async/await není nic jiného než syntaktický cukr, který z programátora jenom snímá nutnost používat napřímo promisy (nebo jiný podobný mechanismus) a překladač je tam doplňuje sám. Takže všechno, co platí pro promisy (popř. ten jiný podobný mechanismus), platí i pro async/await kód.
2. neexistuje žádný zázračný "neblokující kód", který automagicky vede k vyššímu výkonu. Celý je to zcela prostý: pokud mám operace A, B, C, kde A a B jsou vzájemně nezávislé a C je závislé na A i B, tak se hodí A a B spustit zaráz a C až potom, co A i B doběhnou. Zázračný "neblokující kód" je samozřejmě při čekání na A+B
blokovaný 
To je celý princip a je úplně jedno, jaká syntaktická wifikundace se použije k jeho zápisu.
3. díky async/await zápisu sice kód vypadá jako seriový (synchronní), ale to jenom vypadá a pořád je potřeba myslet na to, že smyslem té celé srandy je to, aby A a B mohly běžet
potenciálně paralelně, protože to jediné je zdrojem toho potenciálního nárůstu výkonu, žádnej jinej magickej zrychlovací mechanismus tam není a být nemůže.
Zobrazit příspěvky
