Vastus 1:

Nii sündmustepõhises kui ka mitme keermestatud paradigmas töötab kood opsüsteemi protsessis.

Kui protsess töötab mitu lõime, jagavad need lõimed protsessimälu (aadressiruumi) nii lugemiseks kui ka kirjutamiseks.

Node.js-i käivitav JavaScript on disainitud ühe keermega. Iga funktsiooni käitamine on garanteeritud töö lõpuni ja selle funktsiooni käitamise ajal ei töötata ühtegi muud JavaScripti koodi praeguses protsessis. Looduslikult asünkroonseid sündmusi (võrk, ketta sisend-väljund, taimerid, muu riistvara ja opsüsteemi sündmused) haldab mootor, mis lisab nende sündmuste töötlejatena registreeritud JavaScripti funktsioonid (või tagasilükkamised) sündmuse silmuste järjekorda, mis täidetakse pärast järjekorra ees olevad funktsioonid on lõppenud.

Mitme keermega paradigmas juhivad kaks või enam lõime paralleelselt koodi, nii et funktsiooni käitamise ajal võib erinev protsessorituum käivitada ka erinevat kooditükki, lugedes või kirjutades samadele mäluaadressidele. Selle tulemuseks võib olla mälu oleku ebaühtlus, kui kood ei kasuta jagatud mälule juurdepääsu haldamiseks spetsiaalseid operatsioonisüsteemi mehhanisme (sünkroniseerimise primitiivid).



Vastus 2:

See on hea küsimus: "Mis vahe on Node.js-i sündmuspõhisest arhitektuurist ja mitmekeelsest programmeerimisest teistes keeltes?"

Saame ja peaksime seda natuke lahti lõikama.

  • Sõlme sündmustepõhine arhitektuur.

Sündmustepõhine arhitektuur ei ole sõlme jaoks eksklusiivne, nt Tornado (Python), Vertx (Java), Akka (Scala), ReactiveX (mitu keelt).

  • Mitme keermega programmeerimine teistes keeltes.

Pange tähele, et JavaScript ei toeta oma disainilahendusel mitut lõime. Kuigi see toetab veebitöötajaid, mis minu teada võivad niitidena toimida.

Nii et sündmuspõhine pole sõlme ainulaadne ja sõlme saab teha mitme keermega.

Seega võib siin olla kaks küsimust: “Mis vahe on sündmuspõhiselt versus mitme keermestamise vahel” ja “Mis vahe on sõlmel ja muudel keeltel (raamistikel)”. Keskendun viimasele, kuna see näib olevat küsimuse eesmärk.

Ma ütleksin, et sõlme teeb eriliseks see, et autor lõi selle eesmärgiga vältida veebirakenduste ehitamisel IO blokeerimist. Sõlmekogukonna kultuur on rõhutada mitteblokeeriva IO tugevust ja sellele tugineda. Te ei leia liiga palju kõnesid blokeerivaid kolmanda osapoole raamatukogusid. Kuna sõlme kasutav arendaja, ei hakka tõenäoliselt oma koodis peeneid blokeerimistoiminguid tegema. Kui teistes keeltes võib naiivne arendaja kogemata väga ebatõhusaid kõnesid blokeerida, näiteks lugemine andmebaasiühendusest.

Peale selle peaksite tõesti lugema mitut samaaegsuse mudelit ja mõistma nende plusse ja miinuseid. Boonuspunktid selle hindamise eest, miks mitmekeermestamine oli nii pikka aega vastuvõetav.



Vastus 3:

kontseptuaalseid erinevusi on üsna kerge pea ümber kerida.

Sündmuspõhise arhitektuuri korral töötab teie programm pidevas ühe keermestatud ahelas (võite sõlmes teha ka mitme keermestamise, kuid ärge selle pärast muretsege). Kui sündmus süttib, on töö üles pandud kõnepostil, millega tuleb vabal ajal saadetega tegeleda.

Mitme keermega arhitektuur saadab tavaliselt uue lõime, kui see peab toimingut ootama. Niisiis, helistate andmebaasi ja kerite uue lõime, mis viib läbi kõik vajalikud asjad ja teeb kõik, mida vaja, ning sõlmib või liidab algse lõime.

Mõlemad meetodid on erinevate asjade jaoks väga kasulikud. Sündmustepõhine on suurepärane kasutajaliidese ja serverite jaoks, kuna teie programm ei tea, millal uus paar toimub ja sageli satuvad sündmused purunemisse. Keermestamine on vajalik arvutuslikult raskete tööde jaoks, kus soovite probleemi tükeldada palju väiksemateks tükkideks (või lähenete oma ühe keermestatud aasa piirile).