Event table / queue / loop és a többiek
Sziasztok, kicsit elkezdtem utanaolvasni a JS engine mukodeserol es a bongeszovel valo kapcsolatarol. Par dolog vilagossa valt, de van olyan kerdes amirol egymasnak ellentmondo infokat talalok.
Most nagyon roviden leirnam, hogy eddig mire jutottam es mi az ami meg mindig nem vilagos szamomra.
Megkoszonem, ha valaki megerositene/cafolna az altalam leirtakat, es a kerdesekben barmilyen infoval szolgalna.
1. Maga a JS engine egyszalu, szinkron mukodesu (call stack LIFO), a bongeszoben futo JS mar kepes futni aszinkron modon.
2. A JS kornyezet resze (ami biztos): a heap es a call stack
3. *Az event queue-ban nem vagyok biztos... Ez a JS engine vagy a browser resze?
4. Az aszinkron mukodest a bongeszo segit megvalositani, melynek resze a browser API-k (pl. timer) es melyben implementalva van az event loop is.
5. Az event table a browser API-resze.
6. *Ha az event queue a JS engine resze, akkor az hogy tud mukodni event loop nelkul, ami mar nem az JS engine resze. Tudtommal az event loop pakolja a stack-re a queue-ban levo taszkokat. Esetleg van valami nagyon egyszeru mechanizmus implementalva az engine-n belul, ami kezeli a queue-t es a browser ezt kiegesziti vagy felul definialja?
■ Most nagyon roviden leirnam, hogy eddig mire jutottam es mi az ami meg mindig nem vilagos szamomra.
Megkoszonem, ha valaki megerositene/cafolna az altalam leirtakat, es a kerdesekben barmilyen infoval szolgalna.
1. Maga a JS engine egyszalu, szinkron mukodesu (call stack LIFO), a bongeszoben futo JS mar kepes futni aszinkron modon.
2. A JS kornyezet resze (ami biztos): a heap es a call stack
3. *Az event queue-ban nem vagyok biztos... Ez a JS engine vagy a browser resze?
4. Az aszinkron mukodest a bongeszo segit megvalositani, melynek resze a browser API-k (pl. timer) es melyben implementalva van az event loop is.
5. Az event table a browser API-resze.
6. *Ha az event queue a JS engine resze, akkor az hogy tud mukodni event loop nelkul, ami mar nem az JS engine resze. Tudtommal az event loop pakolja a stack-re a queue-ban levo taszkokat. Esetleg van valami nagyon egyszeru mechanizmus implementalva az engine-n belul, ami kezeli a queue-t es a browser ezt kiegesziti vagy felul definialja?
Miért?
A böngésző alapvetően nem csinál mást, csak a DOM-ot manipulálja, és, ha engedélyezve van a javascript, azt futtatja az adott helyen. Működés közben az eseményekre fel lehet iratkozni javascriptből.
Most erre mit valaszoljak?!?!
Belső
Nem tudom, manapság mi a
Akkor lehet hasznos, ha
Nem tudom biztosan, hogy mi
Tulképp az engine-nek nem muszáj implementálnia, elég valami interface-t adnia hozzá, viszont kötelezővé teheti, hogy implementálva legyen, ha async-await használva lesz. Ahogy nézem a V8 esetében van egy alap implementáció, amit felülírhatnak, ha akarják: link
Event loop
Amikor megnyitsz egy html oldalt, a böngésző elkezdi elkészíteni a DOM fát. Amikor talál egy <script> elemet, akkor az event loop-ba bekerül implicit a tartalma, vagy ha van src attribútuma, betölti, és az kerül be, majd meghívja a JS motort, ami futtatja, és leáll. Ekkor a működése szinkronnak látszik. Folytatódik a feldolgozás, majd a legvégén meghívja az onload eseményt. Ez után a böngészőben történő események (kattintás, egérhúzogatás, időzítő stb.) explicit hozzá tudnak adni a sorhoz.
Az async-await nem más, csak szintaktikai sugár promiszokra, azok meg kvázi egyszerű függvények, amik eltakarják az aszinkronitást.
Az egész olyan, mint egy futószalag, amin jönnek a dobozok, és a dobozokban lévő JS kódot futtatja a motor. Az egyes dobozok között kisebb-nagyobb rések lehetnek.
Akkor mondom egyszerűen. Az
Ezzel nagyjából egyetértek. Az async-await nagyjából egy sugar syntax összegyúrva egy speciális generator-al. Annyi a különbség, hogy yield helyett await van, generator helyett async function és csak Promise-eket lehet yield-elni, a generator meg ezeket várja be, hogy resolve vagy reject lesz az eredményük, és ettől függően next-et egy throw-ot hív magán. Szóval az igazi áttörtést itt a generators hozta, az új feature meg hogy a függvény végrehajtását meg lehet szakítani, és ki-be lehet ugrálni a függvényből. Igy nincs szükség callback-re minden egyes yield után, és nem kell azzal foglalkozni, hogy átadjuk a változókat egyik callback-ből a másikba. Ezek azért nagyon macerásak voltak előtte...
https://stackoverflow.com/que
Ha jol ertem amit irtnak, nincs implementalva az engineben.
Node is a V8-at hasznalja es az event loop a libuv-ban van implementalva.
Table
Az event queue-ben vannak az ötös hozzászólásban leírt dobozok, amit az event loop dolgoz fel, tehát mindkettő a JS motor része.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop
Koszonom az eddig
@Gabor: Onnan indult az egesz, hogy egyszeruen csak nem ertettem, hogy mi is az aszinkron mukodes, hogyan valosul meg. Ezert elkezdtem turni a netet, termeszetesen egy csomo uj dolog jott szembe, aminek szinten utanaolvastam.
Igy allt ossze bennem az a par allitas illetve kerdes, melyeket feltettem.
Az meg mar csak a hab volt tortan, hogy a setTimeout nem az engine resze, hanem a Timer browser API-e. Szoval merges lettem, hogy rohadtul nem tudom, nem ertem...
Event table: furcsa mod tobb cikk is hivatkozik ra, de speciben nem talalom. Tehat ez 5. sort atminositem inkabb kerdesnek, hogy egyaltalan letezik-e, vagy mirol beszelnek akkik errol irnak.
@Inf3rno: az elso linket meg nem olvastam, a masodikkal mar talalkoztam.
Ez azt allitja, hogy van valamilyen event loop az engineben. TERMESZETESEN ennek ellent mondo cikkeket is talaltam, nehogy mar megertsem a dolgokat :).
Pl. ezek:
https://www.quora.com/Does-Node-js-have-more-than-1-event-loop-task-queue
https://blog.risingstack.com/writing-a-javascript-framework-execution-timing-beyond-settimeout/
Es a W3C is a broeserben specifikalja. Akkor csak itt van mar.
https://www.w3.org/TR/html5/webappapis.html#event-loops
Lehet az engine-ben is valami
Nézz bele ebbe, ez se rossz, bár nem js, de a lényeg ugyanaz: https://webdev.dartlang.org/articles/performance/event-loop Amúgy így belegondolva mielőtt beemelték a Promise-eket a nyelvbe, azelőtt gyakorlatilag szinkron volt a JS engine, és minden aszinkronitást a browser engine adott hozzá az event queue-el és az event loop-al. Azóta már szétvált a dolog két queue-re, a loop meg gondolom közös.
Igazából nekem annyira nem világos, hogy a microtask queue miért lett aszinkron. Igy első ránézésre nem látom az okát. Ha valami non-blocking dolgot hívunk belőle, akkor úgyis továbbmegy a kód végrehajtása. Gondolom biztos jó oka van, mert setTimeout-ot, meg ilyesmiket használnak a Promise shimek, de még nem jöttem rá, időm meg most nem nagyon van utánanézni.
Az elso mondattal egyetertek
A link jonak tunik, este atolvasom.
Viszont a queue-k szamat illetoen, eddigi bongeszeseim alapjan arra jutottam, hogy tobb is lehet belole:
https://cdn-images-1.medium.com/max/800/1*-MMBHKy_ZxCrouecRqvsBg.png
TALAN, ezert is implementalnak kulon event loopot, hogy optimalizaljak a tobb queue kezeleset. De ez csak feltetelzes...
Persze, simán lehet, hogy
Ez se rossz amúgy: https://abc.danch.me/microtasks-macrotasks-more-on-the-event-loop-881557d7af6f
Koszi szepen!
Sor
Ezt a 13-asra szerettem volna válaszolni, de ide is jó. Az általad linkelt cikk szerint is végeredményben egy event loop van, egy macro taszk után megnézi, a micro taszkok között van-e új, ha igen, mindet végrehajtja, majd megint jön egy macro. Tehát teljesen soros működésű és egy sor van összesen több forrással.