ugrás a tartalomhoz

Event table / queue / loop és a többiek

mahoo · Okt. 31. (Sze), 10.57
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?
 
1

Miért?

Hidvégi Gábor · Okt. 31. (Sze), 11.22
Miért érdekel az, amit kérdezel? Min változtat, ha tudod, hogy az event queue a böngésző vagy a JS motor része?

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.
2

Most erre mit valaszoljak?!?!

mahoo · Okt. 31. (Sze), 11.24
Most erre mit valaszoljak?!?! Csak...
4

Belső

Hidvégi Gábor · Okt. 31. (Sze), 19.09
Ezek belső dolgok, és hozzájuk férni, dolgozni velük nem lehet, csak ha böngészőt fejlesztesz.
7

Nem tudom, manapság mi a

mind1 valami név · Okt. 31. (Sze), 19.41
Nem tudom, manapság mi a divat, nekem anno rengeteg dologban segített, hogy bár nem kellett hardverrel dolgoznom, de ismertem a működését úgy-ahogy. Szóval a kérdés nekem nem tűnik annyira értelmetlennek akkor sem, ha nem fejleszt böngészőt.
10

Akkor lehet hasznos, ha

inf3rno · Okt. 31. (Sze), 20.30
Akkor lehet hasznos, ha valamit js kóddal akarsz csesztetni, és ezért hozzácsapsz egy js engine-t meg egy API-t mellé a valami csesztetésére. Nem muszáj, hogy az a valami a HTML DOM legyen. Lehet akár egy játék, vagy okos óra, vagy bármi egyéb.
3

Nem tudom biztosan, hogy mi

inf3rno · Okt. 31. (Sze), 12.16
Nem tudom biztosan, hogy mi van az engine-ben, de úgy gondolom, hogy az event loop nem volt része nagyon sokáig. Ez ilyen architekturális kérdés inkább, pl szervereknél van a hagyományos thread/process based, amikor minden kérés kap egy thread-et vagy process-t pl PHP CGI, meg van az event based, amikor egy process szolgálja ki az összes kérést event loop-al. link Szóval alapból a sync js-nek nincs szüksége ilyesmire. Viszont onnantól, hogy bejött az async-await már nem ennyire tiszta a kép, mert ahhoz viszont szükséges az event loop...

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
5

Event loop

Hidvégi Gábor · Okt. 31. (Sze), 19.24
Az event loop a kezdetektől fogva a JS motor része, a benne levő elemeket dolgozza fel a JS egyesével. Az elemek belekerülhetnek explicit és implicit módon.

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.
8

Akkor mondom egyszerűen. Az

inf3rno · Okt. 31. (Sze), 20.18
Akkor mondom egyszerűen. Az engine-ben annak kell kötelezően benne lennie, ami az ECMAScript szabványban benne van. A szabványban sehol nem találsz még csak említést sem event loop-ról, mert nem része a nyelvnek. link Aki csinálja a böngészőt és az engine-t, azok majd eldöntik, hogy melyikbe kerüljön bele, az engine-ben benne lehet, de opcionális, ahhoz, hogy normálisan működjön a böngészőben a JS, meg nyilván szükség van rá.


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.


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...
11

https://stackoverflow.com/que

mahoo · Okt. 31. (Sze), 20.38
https://stackoverflow.com/questions/43814483/where-is-the-main-event-loop-in-the-firefox-source-code

Ha jol ertem amit irtnak, nincs implementalva az engineben.
Node is a V8-at hasznalja es az event loop a libuv-ban van implementalva.
6

Table

Hidvégi Gábor · Okt. 31. (Sze), 19.36
Erről az event table-ről még nem hallottam, mi az?

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
9

Koszonom az eddig

mahoo · Okt. 31. (Sze), 20.28
Koszonom az eddig valaszokat!!! Most van idom irogatni...

@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
12

Lehet az engine-ben is valami

inf3rno · Okt. 31. (Sze), 20.46
Lehet az engine-ben is valami default, amit a browser felülír. Talán az a rész hiányzik nálad, hogy 2 queue van. Az egyik a job queue, ahova a Promise-ek, ilyesmik is bekerülnek, a másik meg az event queue, ahol a DOM-os események mennek. Szokás ezeket meg micro és macro task queue-nek is emlegetni, meg még biztosan van vagy ezer nevük. Ami a standard js-hez kell, az a job/microtask queue meg egy loop, ami azt forgatja. Az event queue meg az event loop az böngésző sajátosság, és akár lehet külön microtask loop is az event loop alatt, bár gondolom a legtöbb implementációnál egybe rakják az egészet. Én is csak mostanában olvasgattam a témában, mert kellett valamihez ez a micro és macro task különbség.

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.
13

Az elso mondattal egyetertek

mahoo · Okt. 31. (Sze), 20.56
Az elso mondattal egyetertek (jelenlegi tudasom alapjan:))
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...
14

Persze, simán lehet, hogy

inf3rno · Okt. 31. (Sze), 21.01
Persze, simán lehet, hogy több van. A 2 inkább a minimum, ami kell, hogy elmenjen a böngésző a mostani js szabvánnyal.

Ez se rossz amúgy: https://abc.danch.me/microtasks-macrotasks-more-on-the-event-loop-881557d7af6f
15

Koszi szepen!

mahoo · Okt. 31. (Sze), 21.11
Koszi szepen!
16

Sor

Hidvégi Gábor · Okt. 31. (Sze), 21.30
Szerintem egy sor van, aminek több forrása lehet, pl. időzítő, DOM, hálózati események. Ha nem így lenne, az nagyon nagy káoszt okozna.

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.