Javascript co się dzieję pod spodem

Question

 

Hej wszystkim, ostatnio staram dowiedzieć się jak wykonywany jest "pod spodem" kodo w node i przeglądarce. na podstawie kilku zagranicznych tutoriali i artykułów narysowałem powyższy schemat w którym nie rozumiem kilku rzeczy, mam nadzieję że ktoś rozjaśni mi to tutaj ;).

Na samej górze w pierwszym wierszu jak widać mamy liste różnych komend

• HTTPS - zapytanie https np. do zewnetrznego serwera
• FS - odczyt z jakiegoś pliku
• CRYPTO - nodowa biblioteka do np. hashowania haseł
• PROMISE - jakaś asynchroniczna operacja

Z tego co rozumiem wszystkie operacje FS i CRYPTO korzystają z silnika V8 który przy pomocy Thread pool'a wykonuje kilka operacji jednocześnie (wszystko jest obliczane przez nasz procesor). I tu moje pytanie co z innymi operacjami które z tego nie korzystają :

• Co z operacjami typu HTTPS ? Słyszałem że operacje wykorzystujące networking jak np. zapytanie https zostają z bezpośrednio zlecane do wykonania OS i jego odpowiedź ląduje w Task Queue ale nie umiałem znaleźć potwierdzenia.
• Co z promisami ? One same jak np. setTimeout zostają wykonywane przez webApi i tal samo callback ląduje w Task Queue ale też nei umiałem znaleźć potwierdzenia mojej teorii.
• Czym różni się pętla zdarzeń dla przeglądarki a node ? Czy czym się różni ?
• Znacie może jakieś fajne miejsca gdzie tego typu rzeczy są w fajny sposób wyjaśniane ?

Wiem że troche przydługo ale mam nadzieję że ktoś będzie w stanie mi wyjaśnić to ;) 

Answer 1

• Czym różni się pętla zdarzeń dla przeglądarki a node ? Czy czym się różni ?

Pętla w przeglądarce jest opisane w specyfikacji HTML. Ta w Node.js jest inna, bo nie jest ptzeglądarkowa i jest oparta o libuv.

• Co z promisami ? One same jak np. setTimeout zostają wykonywane przez webApi i tal samo callback ląduje w Task Queue ale też nei umiałem znaleźć potwierdzenia mojej teorii.

setTimeout() nie jest promise'em. W JS-ie jest rozróżnienie na taski (i tym jest właśnie setTimeout()) oraz microtaski (w tym promise). I one posiadają dwie różne kolejki. Kolejna microtasków jest opróżniana osobno i – w przeciwieństwie do tasków – zawsze są wykonywane wszystkie (nie po jednym, jak taski). Fajnie to widać w wizualizatorze.

• Co z operacjami typu HTTPS ? Słyszałem że operacje wykorzystujące networking jak np. zapytanie https zostają z bezpośrednio zlecane do wykonania OS i jego odpowiedź ląduje w Task Queue ale nie umiałem znaleźć potwierdzenia.

Wszystko, co możliwe, jest zlecane do OS-a – dlatego zresztą te wszystkie operacje są asynchroniczne. Inaczej cały program by był zblokowany, aż task nie zostałby wykonany. 

Comments

Dzięki za wizualizator i podpowiedź w sprawię tych microtaski (doczytam i pobawię się tym), natomiast nurtuje mnie dalej droga jaką przebywają te niektóre komendy np. : 

• FS - np. odczytanie z pliku  
  1. Komenda ląduje na call stacku
  2. Ze stacku jej zdanie jest zlecane jakieś bibliotece C++ należącej do V8 (z racji że jest to asynchroniczne działanie z call stacku to zadanie jest ściągnięte i kod leci dalej)
  3. Ta biblioteka C++ tworzy Thread Pool i w jednym z jego wątków zleca wykonanie zdanie odczytu z jakiegoś pliku
  4. Następnie to zadanie (chyba z tego co rozumiem za pomocą libuv) jest przekazywane do OS gdzie następuje odczyt (słyszałem że to nie jest takie proste i zwracane na początku są jakieś informacje o pliku czy dysku a dopiero potem odczyt ale upraszczam bo nie ma to tu znaczenia)
  5. Odczytano plik wiec następuje dodanie callbacka tego zadania do Task Queue (albo microtaska - nie doczytałem jeszcze o nich :P)
  6. Jak call Stack jest pusty następuje wykonanie callbacku z Task Queue

Jeżeli coś powaliłem albo o czymś zapomniałem to daj proszę znać :) 

I teraz moje pytania: 

• Co z różnego rodzaju zadaniami które nie mają swojej implementacji w V8 czy libuv bo chyba nie wszystkie są tam obsłużone prawda ?
• Jeżeli są takie nieobsłużone to co z mimi sie dzieje jak zostają wywoływane z call stacka (po punkcie 1), lecą bezpośrednio do OS czy mają jeszcze jakiś pośredników ?

Sorry że znowu zrobiłem mały esej ale temat jest gruby, a ja po dwóch tygodniach zgłębiania go czuję że mam więcej pytań niż odpowiedzi :P 

---

V8 to silnik JS z przeglądarki Chrome, on nie ma żadnej biblioteki w C++ do operacji na plikach. Wszystkie takie rzeczy są delegowane do zewnętrznych bibliotek, w tym tych dostarczanych przez Node.js. Jak dokładnie się to dzieje, to można poszperać w kodzie źródłowym Node.js. Samo API modułu fs napisane jest w JS-ie, ale operacje na plikach odsyłane są do wewnętrznego bindingu (szerszy opis), który wskazuje na jedną z bibliotek w katalogu src/ (prawdopodobnie node_file).

Co więcej, to raczej nie ta biblioteka tworzy thread pool, tylko ten thread pool jest częścią libuv. Tak jakby Node ma zawsze "gotowe" wątki, do których przerzuca operacje asynchroniczne, takie jak operacje na plikach.

W sumie ciekawi mnie, po co Ci aż tak dokładne informacje o tym, jak działa Node.js?

---

Hmm głównie ciekawość, mniej więcej wiem już jak używać i pracować z JS wiec myśle że następnym etapem jest "zajrzenie pod maskę", i dowiedzenie sie jak i czemu dane rzeczy są wykonywane :P

Answer 2

Całe node.js opiera się o silnik V8, nie tylko te moduły które podałeś.

W javascript jest taka trochę oszukana asynchroniczność, bo tak naprawdę tylko najbardziej podstawowe i wymagające operacje są rzeczywiście asynchroniczne. Cały pozostały kod js będzie wykonywany synchronicznie przez główną pętlę programu, która co chwilę sprawdza czy jakaś zlecona operacja już się skończyła. Dlatego np. nie można napisać w js jakiegoś bardziej wymagającego zadania i odpalić go w innym wątku, by nie zrobił freeza na innych zadaniach (do tego są webworkery)

Zapytania http to jedne z tych podstawowych operacji i są wykonywane rzeczywiście asynchronicznie.

setTimeout tak naprawdę mogłoby być w pełni synchroniczne. Główna pętla programu zauważy, że dany czas już minął więc wywoła callback. W praktyce chyba do końca tak nie jest.

Co do różnic np. tutaj są opisane: https://dev.to/jasmin/difference-between-the-event-loop-in-browser-and-node-js-1113

Comments

Asynchroniczność w JS-ie jest w dużej mierze rezultatem jednowątkowości języka. Dzięki temu poszczególne rzeczy nie blokują siebie nawzajem. To, że event loop działałby jak synchroniczny, jest jedynie szczegółem implementacyjnym, bo na poziomie języka tego nie widać. Dlatego twierdzenie, że setTimeout() mógłby być synchroniczny, wprowadza w błąd. Tak długo, jak JS jest jednowątkowy, nie mógłby być.

Dlatego np. nie można napisać w js jakiegoś bardziej wymagającego zadania i odpalić go w innym wątku, by nie zrobił freeza na innych zadaniach (do tego są webworkery)

To też jest IMO trochę niefortunnie określone, bo web workery są de facto osobnymi watkami (co jest tym bardziej widoczne w Node.js).

---

@jankustosz1,  

dzięki za odpowiedź i link do różnic pomiędzy tymi dwoma pętlami, natomiast mam zagwozdkę dotyczą petli zdarzeń w node o ile ta w przeglądarce jest świetnie wyjaśniona między innymi tutaj https://www.youtube.com/watch?v=8aGhZQkoFbQ&t=1431s&ab_channel=JSConf, to ta node'owa stanowi dla mnie trochę zagadkę.
Przykładem jest to zdjęcie pokazujące jej działanie :

• W powyższym filmiku wspominano że obie petle (node vs browser) są podobne różnicą głównie jest to że operacje jednej (brwoser) są wykonywane przez WebAPI a drugiej (node) przez C++ libraries, to czemu scheamty mają zupełnie inne ?
• Nawet w artykule który mi podesłałeś mówione jest o Call Stack'u ale na schemacie nigdzie go nie ma  ?
• Na samym schemacie pokazane jest jakoby wszystkie operacje typu networking, db, fs czy nawet inne są wykonywane przy pomocy thread poll'a a z tego co mi wiadomo to nie przykładem jest http request

Jakbyś mógł mi to wyjaśnić albo podesłać link do jakiegoś video albo artykułu to byłbym wdzięczny, dokumentacje node'a dotyczącą event loop czytałem chyba z 3 razy ale nie rozjaśnia mi jakoś tematu :/

Update ->

Znalazłem właśnie inny schemat który troche lepiej pokazuje działanie Event Loopa w node i w sumie odpowiada na moje dwa pierwsze pytanie Call Stack jest oraz sam Event Loop jeżeli chodzi o budowę jest podobny zarówno dla przeglądarek jak i node'a, jedyne co dalej jest dla mnie zagadką to moje trzecie pytanie 

---

Wydaje mi się, że to może wynikać z tego, że system operacyjny udostępnia możliwość odbierania danych po tcp w sposób nieblokujący. Gdyby jedyny sposób odebrania danych był poprzez wywołanie syscalla i oczekiwanie aż się zakończy to trzebaby zrobić nowy wątek i trafiłoby to do Thread Poola. Jest jednak możliwość spytania czy są jakieś dane do odebrania, jak nie ma to nie ma co odbierać. Obstawiam, więc że korzystają z tej wersji nieblokującej i dzięki temu nie jest potrzebny osobny wątek.

---

@Bish0p, a w sumie skąd masz informację, że HTTP nie leci przez thread poola?