Forum » Programiranje » [JS] Asinhronost
[JS] Asinhronost
marjan_h ::
Ne razumem dobro kaj imajo promises v zvezi z asinhronim delovanjem kode. Zdej če hočem razumeti await/async moram prvo razumeti promises. Tisto s callback funkcijo razumem, da pač kličeš eno funkcijo, ki potem na koncu poskrbi da se refresha tisti del ki je odgovoren za asinhronost. Pa zakaj await keyword če napišem pred ukazom, čaka da se tisto naredi do konca. A ni smisel, da naredimo nekaj asinhrono?
Če zna to kdo v slovenščini razložiti, ker sem kar nekaj tutorialov prebral na spletu. Mogoče je jezik ali pa zahtevnost višja.
Če zna to kdo v slovenščini razložiti, ker sem kar nekaj tutorialov prebral na spletu. Mogoče je jezik ali pa zahtevnost višja.
jype ::
Ko awaitaš s tem poveš mašineriji, da se lahko ukvarja z drugimi rečmi, dokler se tista reč, ki jo awaitaš, ne zaključi. Promisi so samo ena oblika abstrakcije tega, da imaš callback (torej funkcijo, ki jo podaš nekomu, ki jo pokliče, ko konča, zato da vmes mašinerija lahko počne druge reči). V starih časih nitenja si to praktično vedno počel "okol rit u varžet" s sporočilnimi vrstami in joini, worker pooli in podobnimi koncepti.
smacker ::
Če uporabiš await, se sprosti CPU med čakanjem, tako da se lahko med čakanjem procesirajo drugi requesti, ki so prišli na strežnik. Bolj ali manj gre samo za drugačno (lepšo) sintakso callbackov. Priporočam branje: https://blog.hellojs.org/asynchronous-j...
marjan_h ::
Sem si prebral. Jype je omenil stare čase nitenja. Torej async/await ne uporablja nitenja? Sicer pa jaz nikoli nisem uporabljal nitenja nikjer, zato mi je ta koncept asinhronosti sedaj nejasen. Ali se potem danes ne uporablja več nitenja?
Ali je ta async/await v JS popolnoma enak kot v Python? Sicer me še zanima, zakaj await ne moreš uporabiti izven funkcije?
Ali je ta async/await v JS popolnoma enak kot v Python? Sicer me še zanima, zakaj await ne moreš uporabiti izven funkcije?
kuall ::
jype ::
wtf. nauči se pisat.Jaz ne seštevam evrov z IEEE754, sinko.
Sem si prebral. Jype je omenil stare čase nitenja. Torej async/await ne uporablja nitenja? Sicer pa jaz nikoli nisem uporabljal nitenja nikjer, zato mi je ta koncept asinhronosti sedaj nejasen. Ali se potem danes ne uporablja več nitenja?Nitenje je samo abstrakcija. Kaj se v resnici dogaja, ko "poganjaš več reči hkrati", je odvisno od precej reči. Kaj se dejansko dogaja na nivoju procesorja (ali več njih) je odvisno od mnogo reči, a v resnici se ti ni treba s tem ukvarjati - bistvenega pomena je predvsem to, da medtem ko en del tvoje kode čaka (recimo na to, da z interneta prileti podatek, ki ga je zahtevala), lahko drug del tvoje kode riše animacije po zaslonu, da uporabniku ni dolgčas, ne da bi ti moral zaradi tega v kodo ki riše po zaslonu tlačit tisoč in eno preverjanje stanja drugih sklopov kode.
Zgodovina sprememb…
- spremenilo: jype ()
marjan_h ::
Ali je ta async/await v JS popolnoma enak kot v Python? Sicer me še zanima, zakaj await ne moreš uporabiti izven funkcije?
youPlonker ::
Torej async/await ne uporablja nitenja? Sicer pa jaz nikoli nisem uporabljal nitenja nikjer, zato mi je ta koncept asinhronosti sedaj nejasen. Ali se potem danes ne uporablja več nitenja?
Async/await je abstrakcija, kako se zadaj ta abstrakcija dejansko vrši se razlikuje od jezika do jezika. .NET kreira nove niti, Node.js uporablja event loop (torej vseskozi obstaja samo "ena nit"), najbrž pa obstaja še kakšen način za ustvarjanje asinhronosti.
Pa zakaj await keyword če napišem pred ukazom, čaka da se tisto naredi do konca. A ni smisel, da naredimo nekaj asinhrono?
Če hočeš da je povsem asinhrono, ne await-aš neke kode. Samo potem v naslednji vrstici tudi nimaš dostopa do vrednosti, ki naj bi jo promise vrnil.
Btw, v JS lahko awaitaš več promisov hkrati (concurrently) s Promise.all .
Spura ::
Vecina async/await mehanizmov uporablja t.i. green threade. Namesto da bi uporabljali OS level threade, ki bi jih OS scheduler razporejal na izvajanje na CPU cores, so green threadi emulacija tega znotraj runtimea samega. Tako z enim OS threadom izvajamo vec green threadov. Lahko uporabljo vec kot en thread (recimo .NET uporablja majhen thread pool za svoj await async, praviloma je pa stevilo threadov v threadpoolu veliko manjse kot stevilo dovoljenih green threadov). Zato da so green threadi sploh uporabnih, mora tak runtime poznati operacijo parkinga teh threadov (iz cesar so narejeni visjenivojskih async/await primitivi). Torej ce vse laufa na enem threadu, kako lahko izvajanje enega green threada suspendiram in dam moznost nekemu drugemu, in predvsem kako bom lahko potem nadaljeval. Recimo ce pogledas C# in yield keyword bos videl da lahko sredi funkcije suspendas green thread.
To se doseze tako, da v teh runtimeih kjer se uporabljajo async/await primitivi, imas nek state machine, ki ubistvu ob yieldu spravi stanje lokanih spremenljivk in podobno za green thread, ki yielda in potem nadaljuje naprej, ko je dosezen nek pogoj (npr promise je izpolnjen preko nekega callbacka ali pa kaj podobnega). Se ena stvar je to, da je tukaj granularnost "schedulinga" pri green threadih druga kot pri navadnih threadih. Pri navadnih threadih se lahko thread na posameznem coru zamenja med dvema strojnima ukazoma, torej je tudi pri single core masini mozno veliko race condition scenarijev.
V nekem JS runtimeu to tako zgleda da se vse izvaja na istem threadu, kar pomeni da se nikoli ne izvajata dve stvari hkrati, hkrati pa je vedno zakljucen vsaj ukaz ko se zamenja kontekst izvajanja, pogosto pa kar cela funkcija, in je torej s strani concurrency problemov stvar lazja in lahko jezik uporabljajo relativni retardi. Nek await ukazi ubistvu parkira trenuten green thread in zacne izvajat katerega drugega. To je bistveno, saj ce ti hoces cakati na rezultat nekega requesta, ki ima seveda nek onSuccess handler, moras zakljucit trenutno izvajanje green threada da lahko drugi opravi procesiranje na requestu na katerega ti cakas.
To se doseze tako, da v teh runtimeih kjer se uporabljajo async/await primitivi, imas nek state machine, ki ubistvu ob yieldu spravi stanje lokanih spremenljivk in podobno za green thread, ki yielda in potem nadaljuje naprej, ko je dosezen nek pogoj (npr promise je izpolnjen preko nekega callbacka ali pa kaj podobnega). Se ena stvar je to, da je tukaj granularnost "schedulinga" pri green threadih druga kot pri navadnih threadih. Pri navadnih threadih se lahko thread na posameznem coru zamenja med dvema strojnima ukazoma, torej je tudi pri single core masini mozno veliko race condition scenarijev.
V nekem JS runtimeu to tako zgleda da se vse izvaja na istem threadu, kar pomeni da se nikoli ne izvajata dve stvari hkrati, hkrati pa je vedno zakljucen vsaj ukaz ko se zamenja kontekst izvajanja, pogosto pa kar cela funkcija, in je torej s strani concurrency problemov stvar lazja in lahko jezik uporabljajo relativni retardi. Nek await ukazi ubistvu parkira trenuten green thread in zacne izvajat katerega drugega. To je bistveno, saj ce ti hoces cakati na rezultat nekega requesta, ki ima seveda nek onSuccess handler, moras zakljucit trenutno izvajanje green threada da lahko drugi opravi procesiranje na requestu na katerega ti cakas.
kuall ::
Ali se potem danes ne uporablja več nitenja?
uporabljaš jih samo ko hočeš, da lahko uporabnik uporablja tvoj program medtem, ko program procesira nekaj drugega. da program ne zablokira po domače. npr če bi hotel pokazat progressbar in pa možnost, da uporabnik med operacijo prekine to dolgotrajno operacijo ali zapre program potem rabiš niti.
drugih pametnih primerov uporabe ni. timer je bolj enostavna izbira npr, če rabiš naredit nekaj na vsake toliko.
genesiss ::
kuall ::
Jaz ne seštevam evrov z IEEE754, sinko.
To ne spremeni dejstva, da ne znaš pisat. Po moje tudi ne razumeš tiste teme, vsaj takrat je nisi, če si se do zdaj naučil dvomim.
Tole:
"torej funkcijo, ki jo podaš nekomu, ki jo pokliče, ko konča, zato da vmes mašinerija lahko počne druge reči"
Bi lahko napisal takole, da bi bilo berljivo:
Nit pokliče callback funkcijo, ko konča.
Callback funkcijo lahko nit pokliče tudi medtem, ko dela na vsake toliko časa, ne samo na koncu.
GupeM ::
Jaz ne seštevam evrov z IEEE754, sinko.
To ne spremeni dejstva, da ne znaš pisat. Po moje tudi ne razumeš tiste teme, vsaj takrat je nisi, če si se do zdaj naučil dvomim.
Tole:
"torej funkcijo, ki jo podaš nekomu, ki jo pokliče, ko konča, zato da vmes mašinerija lahko počne druge reči"
Bi lahko napisal takole, da bi bilo berljivo:
Nit pokliče callback funkcijo, ko konča.
Callback funkcijo lahko nit pokliče tudi medtem, ko dela na vsake toliko časa, ne samo na koncu.
Ne vem, če ni Juretov zapis bolj razumljiv. Vsaj meni se zdi.
Zgodovina sprememb…
- spremenil: GupeM ()
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Python primer async/awaitOddelek: Programiranje | 2147 (1253) | jype |
| » | C# .net class vs .net core async await issueOddelek: Programiranje | 1703 (1463) | detroit |
| » | [UWP] [C#]Oddelek: Programiranje | 4207 (2237) | BivšiUser2 |
| » | [.NET]asinhrona procedura v web service metodiOddelek: Programiranje | 832 (678) | darkolord |
| » | AsinhronostOddelek: Programiranje | 2586 (2355) | mihies |