Zdravim,
vie mi niekto polopate vysvetlit na čo sú dobré generátory v JS? Prečítal som niekoľko článkov a stále mi vôbec nie je jasné čo to má ako byť.
Argumentuje sa, že to zabráni callback hell, ale mne to príde, že namiesto callback hell tam teraz bude generator hell. Okrem toho pri použíti
generátorov mi vôbec nie je jasné ako aplikácia prebieha, kedy sa čo vykoná, pri callbackoch sa mi o tom uvažuje oveľa jednoduchšie.
Ďakujem.
Citace od: Vertex kdy 12. 08. 2015, 16:41:55
na čo sú dobré generátory v JS?
V podstatě se můžete dostat k vymezené kontinuaci (angl. delimited continuation), která jde použít nejvýše jednou a nemůže předat hodnotu zpět do funkce (
next nebere žádný argument). Když píšete callbacky, musíte udělat podobnou transformaci ručně - u generátorů to udělá prohlížeč za vás.
Yield si můžete představit jako throw (tj. příkaz vyhazující výjimku), s tím rozdílem, že se později po vyhození a odchycení výjimky můžete vrátit za místo, kde byla výjimka vyhozena (za příkaz throw), a pokračovat v běhu. Mj. napsal jsem článek Algebraické efekty (http://www.abclinuxu.cz/blog/radekm/2015/6/algebraicke-efekty) - netýká se však pouze generátorů (generátory jsou pouze speciálním případem algebraických efektů).
CitaceOkrem toho pri použíti generátorov mi vôbec nie je jasné ako aplikácia prebieha, kedy sa čo vykoná
IMO dá se na to zvyknout.
Citacejednou a nemůže předat hodnotu zpět do funkce (next nebere žádný argument)
To se mělo týkat pouze iterátorů, jinak samozřejmě
next bere argument, jinak by asynchronní volání nemohly nic vracet.
Generatory v JS neznam, takze to ber s rezervou, na zaklade moji zkusenosti s Pythonem, ktery ma generatory.
Myslim, ze hlavni vyhodou je, ze nemusis umele delit kod do dvou funkci (treba asynchronni volani a callback), ale muzes je dat do jednoho bloku. To zprehlednuje kod, protoze nemusis preskakovat pri cteni do te druhe funkce. Je to tedy v podstate vyjadrenim myslenky, ze sekvencni kod, ktery spolu souvisi, by mel byt definovany v ramci jedne funkce nebo procedury.
Citace od: Vertex kdy 12. 08. 2015, 16:41:55
vie mi niekto polopate vysvetlit na čo sú dobré generátory v JS?
Generátor ušetří neustálé předávání callbacku do funkce, automaticky se uvažuje že callback je na kód následující za NEXT a tento automatický callback se používá YIELD.
Mimo to má callback vlastní stack i lokální proměné existující po celou dobu existence generátoru, takže se s tím dají dělat zajímavé věci, trochu to připomíná kooperativní vlákna. Kód generátoru se tak dá pozastavit tím YIELD a pak se vrátit a pokračovat.
Citace od: JS kdy 13. 08. 2015, 06:24:09
asynchronni volani
Citace od: Radek Miček kdy 12. 08. 2015, 17:45:41
asynchronní volání
V JS nic takového jako asynchronní volání neexistuje, všechno co je zapsáno v javascriptu je bezvýhradně synchronní.
Citace od: k kdy 13. 08. 2015, 08:42:23
V JS nic takového jako asynchronní volání neexistuje, všechno co je zapsáno v javascriptu je bezvýhradně synchronní.
Co tedy určuje třetí parametr
async u
XMLHttpRequest.open (https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest#open%28%29)?
Rovněž handlery událostí jsou spouštěny asynchroně.
async znamená že kód mimo JS, obvykle v C/C++, skutečně běží asynchronně.
Handlery událostí jsou ovšem spouštěny synchronně s ostatními funkcemi, například handler od timeru není spuštěn tehdy kdy má, ale až se ostatní funkce milostivě uráčí skončit, to je v rozporu s asynchronicitou.
Citace od: k kdy 13. 08. 2015, 09:40:08
async znamená že kód mimo JS, obvykle v C/C++, skutečně běží asynchronně.
Podstatné je, že po dobu provádění požadavku může aplikace provádět jinou činnost a nezatuhne. Kdyby to bylo synchronní, tak by aplikace (přesněji volající vlákno - jenže v JS máte obvykle jedno vlákno) zatuhla (např. by nezpracovávala žádné událost), dokud by požadavek neskončil. Je irelevantní, jak je to implementováno.
CitaceHandlery událostí jsou ovšem spouštěny synchronně s ostatními funkcemi, například handler od timeru není spuštěn tehdy kdy má, ale až se ostatní funkce milostivě uráčí skončit, to je v rozporu s asynchronicitou.
Mám na mysli skutečnost, že vyhození události např. pomocí
setInterval(f, 0) nezpůsobí zablokování volajícího kódu, dokud událost není zpracována (dokud
f nedoběhne).
Antonymum synchronní není neblokující. setInterval(f, 0) je neblokující, ale ne asynchronní, kdyby býval byl setInterval(f, 0) asynchronní, potom by k zahájení vykonávání f došlo bezprostředně a v jeden čas by tak běžely dvě funkce najednou a to v JS není možné.
Citace od: k kdy 13. 08. 2015, 11:03:49
Antonymum synchronní není neblokující. setInterval(f, 0) je neblokující, ale ne asynchronní, kdyby býval byl setInterval(f, 0) asynchronní, potom by k zahájení vykonávání f došlo bezprostředně a v jeden čas by tak běžely dvě funkce najednou a to v JS není možné.
tedy asynchronnost lze realizovat pouze na víceprocesorovém (vícejádrovém) systému?
Nejsem velkým znalcem (ani příznivcem) akademické terminologie, ale pokud aspoň lehce kouknu do wikipedie na heslo asynchronní, které není v rozporu jak asynchronnost za ta léta chápu já, nevidím tam jedinou zmínku o současném (paralelním) vykonávaní. Naopak, naprosto v souladu s chápáním synchronních (taktovaných) a asynchronních elektrických obvodů se bavíme o tom, kdy může přijít požadavek. Zda bude zpracován pomocí preemptivního (přerušení, priority) nebo kooperativního multitaskingu (eventloop - až bude volno) je jen implementační detail.
Citace od: v kdy 13. 08. 2015, 11:26:00
tedy asynchronnost lze realizovat pouze na víceprocesorovém (vícejádrovém) systému?
Všude tam kde mají preemptivní multithreading, ve smyslu jak je to známo třeba z C#.
Citace od: Ivoszz kdy 13. 08. 2015, 13:17:10
Naopak, naprosto v souladu s chápáním synchronních (taktovaných) a asynchronních elektrických obvodů se bavíme o tom, kdy může přijít požadavek. Zda bude zpracován pomocí preemptivního (přerušení, priority) nebo kooperativního multitaskingu (eventloop - až bude volno) je jen implementační detail.
To právě není detail, příjem znaků z asynchronní sériové linky musíte zpracovat přiměřeně rychle, ne až nějaký hlupák dokončí pětiminutový výpočet a uvolní tak eventloop, to už budou znaky nenávratně ztraceny.
Citace od: k kdy 13. 08. 2015, 11:03:49
v jeden čas by tak běžely dvě funkce najednou
Citace od: k kdy 13. 08. 2015, 13:33:28
Citace od: v kdy 13. 08. 2015, 11:26:00
tedy asynchronnost lze realizovat pouze na víceprocesorovém (vícejádrovém) systému?
Všude tam kde mají preemptivní multithreading, ve smyslu jak je to známo třeba z C#.
ale na jednoprocesorovém systému nepoběží obě funkce naráz, jsou tedy nutné alespoň dva procesory, ano?
Citace od: k kdy 13. 08. 2015, 13:33:28
Citace od: v kdy 13. 08. 2015, 11:26:00
tedy asynchronnost lze realizovat pouze na víceprocesorovém (vícejádrovém) systému?
Všude tam kde mají preemptivní multithreading, ve smyslu jak je to známo třeba z C#.
Citacekdyby býval byl setInterval(f, 0) asynchronní, potom by k zahájení vykonávání f došlo bezprostředně a v jeden čas by tak běžely dvě funkce najednou a to v JS není možné.
Mj., momentální implementace asynchronních operací v .NET Frameworku (tj. i C#) rovněž nezaručuje, že se asynchronní operace začne vykonávat bezprostředně (např., když jsou všechna vlákna ve ThreadPoolu obsazená). A řada jiných implementací je na tom podobně.
CitaceAntonymum synchronní není neblokující.
Právě bych řekl, že ano. Jinak řečeno synchronní a blokující je totéž (alespoň já to tak chápu) - viz třeba Wikipedie (https://en.wikipedia.org/wiki/Asynchronous_I/O): But such an approach (called synchronous I/O or blocking I/O) would block the progress of a program while the communication is in progress.
Vysvětlím polopaticky, máme funkci FOO pět minut počítající FFT, mezitím přijdou data ze soketu, takže se ihned vyvolá asynchronně funkce BAR a zcela nezávisle na FOO data zobrazí na monitoru. Bez asynchronnosti by se funkce BAR zavolala až po skončení FOO, přesně tak jako se to děje v JS.
Myslím že už jsem to vysvětlil dostatečně. (Uvedené chování jde zajistit i na jednoprocesorovém stroji)
Zdravim,
chcem vám všetkým poďakovať za vaše odpovede. Už mi je to jasnejšie. Ešte sa s tým pohrám aby sa mi to dostalo do krvi.
Vďaka.
Citace od: k kdy 13. 08. 2015, 14:26:23
Vysvětlím polopaticky, máme funkci FOO pět minut počítající FFT, mezitím přijdou data ze soketu, takže se ihned vyvolá asynchronně funkce BAR a zcela nezávisle na FOO data zobrazí na monitoru. Bez asynchronnosti by se funkce BAR zavolala až po skončení FOO, přesně tak jako se to děje v JS.
Myslím že už jsem to vysvětlil dostatečně. (Uvedené chování jde zajistit i na jednoprocesorovém stroji)
Ale my vám rozumíme :), není potřeba to vysvětlovat polopatisticky. Jen nesouhlasíme s vaší definicí (pojetím) toho, co je asynchronní... :D
A jen tak mimochodem, i ten výpočet FFT lze triviálně napsat tak, že bude obsluhovat příchozí požadavky rychleji než to zvládne preemptivní multitasking, který tak propagujete. Změníte pak svou definici asynchronosti?
Citace od: k kdy 13. 08. 2015, 14:26:23
Vysvětlím polopaticky, máme funkci FOO pět minut počítající FFT, mezitím přijdou data ze soketu, takže se ihned vyvolá asynchronně funkce BAR a zcela nezávisle na FOO data zobrazí na monitoru. Bez asynchronnosti by se funkce BAR zavolala až po skončení FOO, přesně tak jako se to děje v JS.
Myslím že už jsem to vysvětlil dostatečně. (Uvedené chování jde zajistit i na jednoprocesorovém stroji)
zřejmě používáte nějakou definici současnosti se kterou nejsem obeznámený
Citace od: v kdy 13. 08. 2015, 15:32:58
zřejmě používáte nějakou definici současnosti se kterou nejsem obeznámený
Používám definici, která je poměrně obecně přijímána (pokud se bavíme o synchronních/asynchronních voláních v oblasti SW) a je stručně popsána takto:
When you execute something synchronously, you wait for it to finish before moving on to another task. When you execute something asynchronously, you can move on to another task before it finishes.
Toto je taky relevantní k původnímu dotazu.
Citace od: Ivoszz kdy 13. 08. 2015, 16:20:01
When you execute something asynchronously, you can move on to another task before it finishes.
Normální člověk tohle pochopí tak, že operace
something se zahájí bezprostředně ihned a volající nečeká na její dokončení a může si mezi tím dělat svoje věci, implicitně z toho vyplývá paralelní běh.
Jistě se to nedá pochopit tak, že se čeká pět minut až volající dá pokoj a pak teprve se zavolá
something.
Citace od: Ivoszz kdy 13. 08. 2015, 16:20:01
Citace od: v kdy 13. 08. 2015, 15:32:58
zřejmě používáte nějakou definici současnosti se kterou nejsem obeznámený
Používám definici, která je poměrně obecně přijímána (pokud se bavíme o synchronních/asynchronních voláních v oblasti SW) a je stručně popsána takto:
When you execute something synchronously, you wait for it to finish before moving on to another task. When you execute something asynchronously, you can move on to another task before it finishes.
Toto je taky relevantní k původnímu dotazu.
"současností" jsem narážel na toto:
Citace od: k kdy 13. 08. 2015, 11:03:49
Antonymum synchronní není neblokující. setInterval(f, 0) je neblokující, ale ne asynchronní, kdyby býval byl setInterval(f, 0) asynchronní, potom by k zahájení vykonávání f došlo bezprostředně a v jeden čas by tak běžely dvě funkce najednou a to v JS není možné.
resp. na to, že funkce "běží najednou", proto neustále melu o více procesorech, jestli funkce mohou běžet "najednou" na jednom procesoru, tak můžou i v javascriptu a tím i asynchronně dle k-ovy definice
Citace od: k kdy 13. 08. 2015, 16:53:32
Citace od: Ivoszz kdy 13. 08. 2015, 16:20:01
When you execute something asynchronously, you can move on to another task before it finishes.
Normální člověk tohle pochopí tak, že operace something se zahájí bezprostředně ihned a volající nečeká na její dokončení a může si mezi tím dělat svoje věci, implicitně z toho vyplývá paralelní běh.
Jistě se to nedá pochopit tak, že se čeká pět minut až volající dá pokoj a pak teprve se zavolá something.
takže hardwarové přerušení není asynchronní, protože po přiřazení handleru se ten nevykoná okamžitě?
Hardware do toho nemotejte, to se tu už důkladně diskutovalo http://forum.root.cz/index.php?topic=11249.msg132438#msg132438 a v zásadě to skončilo, že jedna strana diskutujících uvažovala v rámci hw a druhá v rámci virtuálního stroje (např. jvm).
Celé nedorozumění v případě javascriptu jednoduše spočívá v tom, že lidé zaměňují odložené spuštění (zařazení do fronty úloh) a paralelní běh (současný běh více položek z té fronty), část z nich si pak myslí, že odložené spuštění je znakem asynchronnosti. Navíc celý systém callbacků budí dojem, že si žijí svým vlastním životem a že to celé ,,běží tak nějak naráz". S vyjímkou volání ajaxu ale všechno v javascriptu běží pěkně jedno za druhým. Alespoň v prohlížeči - nevím jak to je v případě node.js a spol, tam je asi možné ledacos.
Citace od: Ondrej Nemecek kdy 13. 08. 2015, 21:09:14
část z nich si pak myslí, že odložené spuštění je znakem asynchronnosti
Pokud nečekáte na výsledek, tak samozřejmě je.
Pokud bych to bral, jako že u asynchronního běhu není přesně dáno, kdy se úloha zadaná k provedení skutečně začne vykonávat a na tento začátek se nečeká, pak by bylo jedno, jak moc paralelně to probíhá. A pak by mě zajímalo, proč některým vadí, že něco něběží +-skutečně paralelně. Že by to byl klasicky zase jen problém definice?
Citace od: k kdy 13. 08. 2015, 16:53:32
Normální člověk tohle pochopí tak, že operace something se zahájí bezprostředně ihned a volající nečeká na její dokončení a může si mezi tím dělat svoje věci, implicitně z toho vyplývá paralelní běh.
Nevyplyva. Na toto tema je dobra prednaska http://blog.golang.org/concurrency-is-not-parallelism (http://blog.golang.org/concurrency-is-not-parallelism). Asynchronni volani jsou forma concurrency, k paralelismu muze dojit ale nemusi (jak uz tu nekdo zminil HW interrupt na jednom procesoru je dobry priklad). Stejne tak existuje paralelismus bez concurrency, typicke priklady jsou pipelining nebo SIMD.
Citace
Jistě se to nedá pochopit tak, že se čeká pět minut až volající dá pokoj a pak teprve se zavolá something.
Myslim, ze duvod tveho nepochopeni (krome vyse uvedeneho) je v tom, ze to co ostatni (Radek) zde oznacuji za asynchronni volani neni nutne zapsano podobne jako synchronni volani
funkce(parametr), ale provadi se to prave predanim callback rutiny. Skoro kazdy jazyk umoznuje "asynchronni volani" v tomto smyslu, aniz by vyzadoval specialni syntaxi.
Citace od: JS kdy 14. 08. 2015, 08:28:49
Citace od: k kdy 13. 08. 2015, 16:53:32
Normální člověk tohle pochopí tak, že operace something se zahájí bezprostředně ihned a volající nečeká na její dokončení a může si mezi tím dělat svoje věci, implicitně z toho vyplývá paralelní běh.
Nevyplyva.
Tímto s Vámi končím, nejste normální a nebudu s Vámi dál ztrácet čas.
Přednáška s chybou již v názvu mě nezajímá.
Citace od: Ondrej Nemecek kdy 13. 08. 2015, 21:09:14
Celé nedorozumění v případě javascriptu jednoduše spočívá v tom, že lidé zaměňují odložené spuštění (zařazení do fronty úloh) a paralelní běh (současný běh více položek z té fronty), část z nich si pak myslí, že odložené spuštění je znakem asynchronnosti. Navíc celý systém callbacků budí dojem, že si žijí svým vlastním životem a že to celé ,,běží tak nějak naráz". S vyjímkou volání ajaxu ale všechno v javascriptu běží pěkně jedno za druhým.
Ano, souhlas.
Citace od: k kdy 14. 08. 2015, 09:34:29
Přednáška s chybou již v názvu mě nezajímá.
Paralelní != konkurentní (https://existentialtype.wordpress.com/2011/03/17/parallelism-is-not-concurrency/) není chyba (většina lidí se například shodne na tom, že konkurentní neimplikuje paralelní).
Citace od: Ondrej Nemecek kdy 13. 08. 2015, 21:09:14
Celé nedorozumění v případě javascriptu jednoduše spočívá v tom, že lidé zaměňují odložené spuštění (zařazení do fronty úloh) a paralelní běh (současný běh více položek z té fronty), část z nich si pak myslí, že odložené spuštění je znakem asynchronnosti. Navíc celý systém callbacků budí dojem, že si žijí svým vlastním životem a že to celé ,,běží tak nějak naráz". S vyjímkou volání ajaxu ale všechno v javascriptu běží pěkně jedno za druhým.
Zajímavé... argumentujeme zde o tom "co si někteří myslí" a nebo co asynchronní odpravdu znamená? A co je tedy odložení spuštění jiného než jedna z možných implementací asynchronicity?
Já měl za to že asynchronní znamená že prostě není synchronní (tj. že když danou část programu zavolám tak nemám jistotu že dokud nedoběhne tak se nic jiného nestane - nepočítejme pro zjednodušení vnější vstupy), a jestli je to tím že to běží po sobě v předem nedefinovaném pořadí (odloženě), nebo paralelně na tom samém stroji a nebo někde na serveru je z pohledu synchronní/nesynchronní irelevantní implementační detail (který se navíc může u jednotlivých instancí programu lišit podle toho na čem zrovna běží).
Citace od: Ondrej Nemecek kdy 13. 08. 2015, 21:09:14
S vyjímkou volání ajaxu ale všechno v javascriptu běží pěkně jedno za druhým. Alespoň v prohlížeči - nevím jak to je v případě node.js a spol, tam je asi možné ledacos.
S tim nemohu souhlasit. Staci stranka, ktera ma dva GUI prvky navazane na Javascript - pak neni vubec jasne, ktery kod se vykona driv, protoze to zalezi na tom, kam uzivatel zrovna klikne. Takze je vysledny program asynchronni, prestoze tim uzivatelem muze byt pomala babicka, ktera vsechno provadi v podstate synchronne.
Neco jineho je CGI skript nebo tzv. inteligentni terminal - ty jsou synchronni - uzivatel zada data, stiskne ENTER a server zpracuje pozadavek (a uzivatel musi cekat, dokud se nevrati odpoved).
aby som prispel troškou bordelu, aj ajax sa dá spraviť synchrónne, čiže už to vlastne ani nie je ajax, ale sjax :)
Tyhle diskuse mne docela baví... :D
Jak už jsem psal někde v počátcích, problém je v definicích a zjednodušování, proto jsem přihodil definici toho, co myslím asynchronností já. A pak tu člověk čte javascript, ale myslí se jen browser, napíše se že veškerý JS běží v jednom vláknu, ale nedodá se že knihovny a IO operace už v tom samém vláknu neběží, a to nemluvím o webworkerech, atd. atd. Když napíšu že na konkurenčním modelu nezáleží, protože je to implementační detail, tak se operuje paralelním během. A nejkomičtější jsou argumenty s pětimintovým čekáním, když v naprosté většině reálných testů a nasazení ten "strašně pomalý" javascript, kde se tak dlouho čeká na odpověď poráží v rychlosti své konkurenty (jako třeba Java) a hlavně má mnohem kratší reakční dobu na požadavek. Právě proto byl také nasazen na webové stránky a jeho asynchronnost (mimochodem, naprostá většina UI je asynchronní na bázi event loopu, aby byla rychlejší doba odezvy) byla jedna z primárních vlastností. A kvůli té "pomalosti" jsou pak do dalších jazyků zapracovávány asynchronní metody volání, vznikají asynchronní frameworky atd., jen proto abychom zpomalili běh programů.... :)
Mimochodem, ta jednovláknost javascriptu je jednou z jeho velkých výhod. Za prvé to zjednodušuje programování při přístupu ke sdíleným zdrojům, za druhé to umožňuje jednoduše a téměř lineárně škálovat výkon s relativně malou spotřebou systémových zdrojů.
Citace od: Ivoszz kdy 14. 08. 2015, 11:37:19
naprostá většina UI je asynchronní na bázi event loopu
S Vámi také končím, označit event loop asynchronní je již mimo moje chápání.
Citace od: k kdy 14. 08. 2015, 12:29:27
Citace od: Ivoszz kdy 14. 08. 2015, 11:37:19
naprostá většina UI je asynchronní na bázi event loopu
S Vámi také končím, označit event loop asynchronní je již mimo moje chápání.
žádný problém, vždyť nikdo nejsme vševědoucí, zkusím vám to vysvětlit na (trošičku vykonstruovaném) příkladu
uživatel klikne na tlačítko, systém zachytí přerušení (to je synchronní zpracování), ale nepodnikde žádnou akci vázanou na funkci tlačítka, ale zprávu uloží do fronty, aplikace kontroluje (v "event loop") jestli něco zmíněnou frontou nepřišlo, pokud ano, podnikne příslušné kroky, tedy pokud se jí to hodí a kdy se jí to hodí - asynchronně vzhledem ke vzniku události
(a)synchronní, (ne)blokující, paralelní, konkurenční, preemptivní, ... vyzná se v tom ještě někdo?
Citace od: Ondrej Nemecek kdy 14. 08. 2015, 16:35:57
(a)synchronní, (ne)blokující, paralelní, konkurenční, preemptivní, ... vyzná se v tom ještě někdo?
Vyzna:
(a)synchronní => udalost
(ne)blokující => volani
paralelní => hardware
konkurenční => software
preemptivní => planovac
Jsou to pribuzne koncepty, jen se kazdy vztahuje na neco jine. ;)
Citace od: v kdy 14. 08. 2015, 13:36:38
To jste do toho zamotal přerušení a zamotal jste i sebe :) Vyvolání obsluhy IRQ je asynchronní záležitost, fronta událostí je synchronní záležitost, event-loop též synchronní záležitost. Asynchronní obsluhu události od IRQ si můžete představit jako pohyb myši, zjevně se hybá i když event-loop zrovna dělá něco jiného.
Citace od: k kdy 14. 08. 2015, 18:24:02
To jste do toho zamotal přerušení a zamotal jste i sebe :)
Jediny, kdo se tady zamotava jste vy:
Citace
Vyvolání obsluhy IRQ je asynchronní záležitost
Urcite? Podle vasi analogie je to take synchronni, protoze vyvolani IRQ je rizene synchronnim hodinovym signalem procesoru...
Pointa je, ze asynchronost je urcita abstrakce reality, nikoli realita. Plynuti casu z hlediska aplikace muze vypadat jinak nez z hlediska operacniho systemu, asi podobne jako nahodny generator nemusi byt nutne realne nahodny (v deterministickem vesmiru se to treba zaridi tezko), staci nahodny z pohledu aplikace.
Fronta událostí n. operací je (resp. může být pokud povoluje pouze seriání zpracování) sychronní vzhledem sama k sobě, ale nikoli vzhledem k provádění kódu který do ní události/operace vkládá.
Citace od: k kdy 14. 08. 2015, 18:24:02
To jste do toho zamotal přerušení a zamotal jste i sebe :)
vy, abyste se nezamotal, námitky ignorujete - co je to ten současný běh funkcí?
Citace
Vyvolání obsluhy IRQ je asynchronní záležitost
přerušení je vyvoláno asnychronně - uživatel klikne kdy se rozhodne, ale kód ISR se provádí okamžitě, za přerušení provádění původního programu, jehož vykonávání pokračuje až to ISR s tím kliknutím dořeší
Citace
fronta událostí je synchronní záležitost
fronta události je datová struktura
Citace
event-loop též synchronní záležitost
"event loop" je konstrukce v programu pro zpracování asynchronně vznikajích událostí, události jsou vyhodnocovány až se program usmyslí, ne okamžitě kdy vzniknou
Citace
Asynchronní obsluhu události od IRQ si můžete představit jako pohyb myši, zjevně se hybá i když event-loop zrovna dělá něco jiného.
já jsem mluvil o kliknutí a aplikaci, ale pokud chcete naznačit, že různé události se mohou zpracovat různými postupy, tak asi máte pravdu
Citace od: v kdy 14. 08. 2015, 19:06:03
vy, abyste se nezamotal, námitky ignorujete - co je to ten současný běh funkcí?
Přerušení do toho zamotalo ISR a tím se nám to zkomplikovalo :) Řeč byla o asynchronním vykonávání funkcí v rámci jedné aplikace. Současný běh funkcí logicky je že v jednom čase se vykonávají dvě funkce a nutný nikoliv postačující předpoklad k tomu je, že druhá funkce nečeká na dokončení první. Technicky se to nejčastěji realizuje pomocí vláken nebo procesů.
Citace od: v kdy 14. 08. 2015, 19:06:03
přerušení je vyvoláno asnychronně
Citace od: v kdy 14. 08. 2015, 19:06:03
"event loop" je konstrukce v programu pro zpracování asynchronně vznikajích událostí, události jsou vyhodnocovány až se program usmyslí, ne okamžitě kdy vzniknou
Citace
To se shodujeme :) ISR je asynchronní, vloží událost do fronty událostí a tím asynchronní obsluha události skončila.
Když má event-loop čas, tak vybere událost z fronty událostí a jednu po druhé synchronně zpracuje, v jeden čas se zpracovává pouze jedna událost.
Citace od: v kdy 14. 08. 2015, 19:06:03
já jsem mluvil o kliknutí a aplikaci, ale pokud chcete naznačit, že různé události se mohou zpracovat různými postupy, tak asi máte pravdu
Ano můžete si vybrat:
A) Událost od kliknutí na tlačítko myši vložit do fronty a událost se zpracuje synchronně vůči všem ostatním událostem.
B) Událost od pohybu myší obsloužit rovnou v ISR a pak se zpracuje asynchronně vůči všem ostatním událostem ve frontě.
Citace od: k kdy 14. 08. 2015, 20:26:17
Současný běh funkcí logicky je že v jednom čase se vykonávají dvě funkce
teď fakt nevím, jestli žertujete
Citace od: k kdy 14. 08. 2015, 20:26:17
Současný běh funkcí logicky je že v jednom čase se vykonávají dvě funkce a nutný nikoliv postačující předpoklad k tomu je, že druhá funkce nečeká na dokončení první.
Není to nutný předpoklad - funkce se mohou střídat (tj. v jednom čase poběží pouze jedna) nebo se jedna z funkcí začne vykonávat až poté, co jiná skončí.
Citace od: JS kdy 14. 08. 2015, 17:36:44
Citace od: Ondrej Nemecek kdy 14. 08. 2015, 16:35:57
(a)synchronní, (ne)blokující, paralelní, konkurenční, preemptivní, ... vyzná se v tom ještě někdo?
Vyzna:
(a)synchronní => udalost
(ne)blokující => volani
paralelní => hardware
konkurenční => software
preemptivní => planovac
Jsou to pribuzne koncepty, jen se kazdy vztahuje na neco jine. ;)
Hmm, to by dávalo smysl.
Citace od: JS kdy 14. 08. 2015, 17:36:44
...
konkurenční => software
...
jen dotaz - já vždy používám výraz "konkurentní", je "konkurenční" v daném kontextu OK oboje?
Citace od: Petr kdy 14. 08. 2015, 21:53:00
Citace od: JS kdy 14. 08. 2015, 17:36:44
...
konkurenční => software
...
jen dotaz - já vždy používám výraz "konkurentní", je "konkurenční" v daném kontextu OK oboje?
doporučuju: http://prirucka.ujc.cas.cz
řekl bych, že "konkurentní" je zkomolenina
Citace od: v kdy 14. 08. 2015, 20:32:16
teď fakt nevím, jestli žertujete
Také fakt nevím, co na tom pořád nechápete.
Citace od: Radek Miček kdy 14. 08. 2015, 21:05:08
Citace od: k kdy 14. 08. 2015, 20:26:17
nutný nikoliv postačující předpoklad k tomu je, že druhá funkce nečeká na dokončení první.
Není to nutný předpoklad - funkce se mohou střídat (tj. v jednom čase poběží pouze jedna) nebo se jedna z funkcí začne vykonávat až poté, co jiná skončí.
Člověk to tady může psát celý den, že takhle to nejde, ale je to marný, je to marný, je to marný. Tímto končím definitivně.
https://www.youtube.com/watch?v=XDJEPjvbbs4
Citace od: v kdy 14. 08. 2015, 22:07:03
...
doporučuju: http://prirucka.ujc.cas.cz
řekl bych, že "konkurentní" je zkomolenina
Jj, máš asi pravdu, "konkurentní" vypadá na programátorskou čengliš.
"Konkurenční" mi ale zase v daném kontextu přijde, jako když v češtině někdo používá "pregnantní" ve významu anglického "pregnant".
Se zkusim přešaltovat na "souběžný" a tu čengliš ze slovníku vyřadit. :-)
Citace od: k kdy 14. 08. 2015, 22:17:11
Citace od: Radek Miček kdy 14. 08. 2015, 21:05:08
Citace od: k kdy 14. 08. 2015, 20:26:17
nutný nikoliv postačující předpoklad k tomu je, že druhá funkce nečeká na dokončení první.
Není to nutný předpoklad - funkce se mohou střídat (tj. v jednom čase poběží pouze jedna) nebo se jedna z funkcí začne vykonávat až poté, co jiná skončí.
Člověk to tady může psát celý den, že takhle to nejde, ale je to marný, je to marný, je to marný. Tímto končím definitivně.
https://www.youtube.com/watch?v=XDJEPjvbbs4
Že to píšete celý den, neznamená, že to tak je.
Citace od: k kdy 14. 08. 2015, 22:17:11
Tímto končím definitivně.
To je dobre, kdyz se ignorantum jako vy (kteri se nechteji nic noveho dozvedet) snazi zde nekteri vzdelani lide (Radek) neco vysvetlit, jde opravdu o zbytecnou namahu.
Jak to chápu:
(a)synchronní znamená, že nějaké dvě věci spolu jsou nebo nejsou sesynchronizovány. Takže když mám dvě zavolání funkcí, jedna zpracovává svůj výsledek déle než druhá, tak není přihlíženo na pořadí volání, ale na délku vykonávání té funkce.
(ne)blokující znamená, že jedna věc (ne)blokuje jinou. Například zavolám první funkci, a hned mohu volat druhou a nemusím čekat na výsledek, protože ten výsledek se mi zpět dopraví jiným způsobem (callbackem).
paralelní znamená, že dvě funkce se vykonávají ve stejný čas (reálně, na více jádrech, ale platí to i když to je jen iluzojní pomocí multitaskingu).
Vychází mi z toho, že často se děje kombinace neblokující asynchronní volání funkce, a když jich zavolám více, tak budou spolu běžet paralelně. Ale neimplikuje to nutnost. Klidně můžu zavolat dvě funkce neblokujíce (s callbackem), oni se mi na sobě nezávisle zavolají (to znamená, že nemám zaručeno, která se spustí první), ale z nějakého implementačního důvodu (http://devel.cz/otazka/async-immutable) se spustí za sebou - takže nejsou paralelní.
Stejně tak bych, když bych se hodně snažil, určitě našel i případ, kdy budu mět asynchronní, blokující, neparalelní...
Správně?