Naučení se asynchronnímu programování

[Zabanovaný Anonymní Troll]

Prisel jsem na to, co to vlastne u sw developmentu to asynchronni znamena. Vztahuje se to k tomu, ze mam nejake behove programove flow, a to flow ma nejakou posloupnost v pogramovem kodu. Mira asynchronity aplikace je mira toho, jak moc se skutecne flow pri behu aplikace, ktere muze byt v podstate reprezentovano Stacktrace vlakna, lisi od posloupnosti kodu aplikace, tak jak ji prirozene vnima programator. Jde tedy o miru asynchronity vzhledem k tradicni programatorske ergonomii pri programovani aplikace. Kdyz se to lisi hodne, ba dokonce je nam stacktrace uplne na govno, jako v pripade Event loop, tak mira asynchronity je vysoka.

Kdyz mam system na zpracovani objedavek, tak vyrobeni objednvky vzhledem k uzivateli je mozna asynchronni prvek, nicmene je to neco odlisneho od pojmu asynchronni programovani.

No a ja rikam, abyste neprogramovali asynchronne, protoze je to na 3.14cu, protoze to nema dobrou ergonomii

Coz mi pripomina, jak asi vypada stacktrace v pripade Coroutin s await async. Zda-li je zmrsena, nebo zda-li vypada stejne jako kdybych asynchronni cast kodu provedl v samostatnem vlakne, tedy ze ta odvetvena cast kodu ma svou vlastni peknou stacktrace.

[Reklama]

[Ondra Satai Nekola]

Prisel jsem na to, co to vlastne u sw developmentu to asynchronni znamena.

Píše člověk, co na to už několik dnů nadává. Teď se už alespoň tváří, že ví na co...

[Jiří Havel]

No a ja rikam, abyste neprogramovali asynchronne, protoze je to na 3.14cu, protoze to nema dobrou ergonomii

Coz mi pripomina, jak asi vypada stacktrace v pripade Coroutin s await async. Zda-li je zmrsena, nebo zda-li vypada stejne jako kdybych asynchronni cast kodu provedl v samostatnem vlakne, tedy ze ta odvetvena cast kodu ma svou vlastni peknou stacktrace.

Takže ty víš, že je to na pendrek a neergonomické a přitom ani nevíš jak vypadá stacktrace?

[Idris]

Prisel jsem na to, co to vlastne u sw developmentu to asynchronni znamena. Vztahuje se to k tomu, ze mam nejake behove programove flow, a to flow ma nejakou posloupnost v pogramovem kodu. Mira asynchronity aplikace je mira toho, jak moc se skutecne flow pri behu aplikace, ktere muze byt v podstate reprezentovano Stacktrace vlakna, lisi od posloupnosti kodu aplikace, tak jak ji prirozene vnima programator. Jde tedy o miru asynchronity vzhledem k tradicni programatorske ergonomii pri programovani aplikace. Kdyz se to lisi hodne, ba dokonce je nam stacktrace uplne na govno, jako v pripade Event loop, tak mira asynchronity je vysoka.

Kdyz mam system na zpracovani objedavek, tak vyrobeni objednvky vzhledem k uzivateli je mozna asynchronni prvek, nicmene je to neco odlisneho od pojmu asynchronni programovani.

No a ja rikam, abyste neprogramovali asynchronne, protoze je to na 3.14cu, protoze to nema dobrou ergonomii

Coz mi pripomina, jak asi vypada stacktrace v pripade Coroutin s await async. Zda-li je zmrsena, nebo zda-li vypada stejne jako kdybych asynchronni cast kodu provedl v samostatnem vlakne, tedy ze ta odvetvena cast kodu ma svou vlastni peknou stacktrace.

Smyčka událostí je synchronní, až použití NIO nebo něčeho podobného dodá kódu na asynchronicitě.

[registrovany_ava]

Coz mi pripomina, jak asi vypada stacktrace v pripade Coroutin s await async. Zda-li je zmrsena, nebo zda-li vypada stejne jako kdybych asynchronni cast kodu provedl v samostatnem vlakne, tedy ze ta odvetvena cast kodu ma svou vlastni peknou stacktrace.

Tohle je dobrá otázka. Krátká odpověď (nejsem expert) je, že záleží na konkrétní implementaci v konkrétním jazyce. Tady je pěkný blogpost, který porovnává jak je to s stacktracem v JavaScriptu a v Rustu: https://fitzgeraldnick.com/2019/08/27/async-stacks-in-rust.html

[Reklama]

[Idris]

Coz mi pripomina, jak asi vypada stacktrace v pripade Coroutin s await async. Zda-li je zmrsena, nebo zda-li vypada stejne jako kdybych asynchronni cast kodu provedl v samostatnem vlakne, tedy ze ta odvetvena cast kodu ma svou vlastni peknou stacktrace.

Tohle je dobrá otázka. Krátká odpověď (nejsem expert) je, že záleží na konkrétní implementaci v konkrétním jazyce. Tady je pěkný blogpost, který porovnává jak je to s stacktracem v JavaScriptu a v Rustu: https://fitzgeraldnick.com/2019/08/27/async-stacks-in-rust.html

V případě kooperativního scheduleru je zásobník vždy jakoby byl kód synchronní.

[luvar]

Nerád by som narušil plodnú diskusiu, ale skúste zadefinovať výraz "non-blocking" a potom opäť hladať definíciu asynchronicity...

Sidenote, je tu nejaký C/C++ kóder? Imho by vedel pekne vysvetlit, naco sa pouziva epoll a preco necakame na prijatie nejakych bajtov po sieti inym sposobom?

Sidenote2: Skusme rozobrat hypoteticku ulohu. Nakodit server, na ktory uploaduju nejake "pocitace" nejake subory a server ich iba uklada na disk. Pre predstavu skusme mat server s procesorom ktory zvladne duke nukem a ma mechanicky disk s rychlostou zapisu napriklad 10MB/s. A klientov dajme 10000 (nech to je 10k problem aspon . Samozrejme kazdy klient cez svoje wifi/bluetooth/idra posiela data rychlostou napriklad 500 bajtov za sekundu a ma za ulohu nahrat 1MB velky subor. Nech je sranda, klienti zacnu posielat subor naraz... (cielom je ukazat rozdiel medzi non-blocking a async. Jeden z nich je nutny na to, aby klient, ktory sa pripoji ako druhy, mohol zacat nieco dalsieho posielat a druhy je nutny, aby to dany cpu zvladol, respektive venoval sa aj robote a nielen "context switchingu")

[Zabanovaný Anonymní Troll]

.

[Zabanovaný Anonymní Troll]

Nerád by som narušil plodnú diskusiu, ale skúste zadefinovať výraz "non-blocking" a potom opäť hladať definíciu asynchronicity...

Sidenote, je tu nejaký C/C++ kóder? Imho by vedel pekne vysvetlit, naco sa pouziva epoll a preco necakame na prijatie nejakych bajtov po sieti inym sposobom?

Sidenote2: Skusme rozobrat hypoteticku ulohu. Nakodit server, na ktory uploaduju nejake "pocitace" nejake subory a server ich iba uklada na disk. Pre predstavu skusme mat server s procesorom ktory zvladne duke nukem a ma mechanicky disk s rychlostou zapisu napriklad 10MB/s. A klientov dajme 10000 (nech to je 10k problem aspon . Samozrejme kazdy klient cez svoje wifi/bluetooth/idra posiela data rychlostou napriklad 500 bajtov za sekundu a ma za ulohu nahrat 1MB velky subor. Nech je sranda, klienti zacnu posielat subor naraz... (cielom je ukazat rozdiel medzi non-blocking a async. Jeden z nich je nutny na to, aby klient, ktory sa pripoji ako druhy, mohol zacat nieco dalsieho posielat a druhy je nutny, aby to dany cpu zvladol, respektive venoval sa aj robote a nielen "context switchingu")

Takze tech 10000 klientu, resp. 10000 socketu, budu obsluhovat v jedinem vlakne pres epoll. Protoze ten disk mi stejne umoznuje jenom sekvenci zapis, tak budu mit druhe vlakno, ktere bude mit frontu na zapisy. No a po bajtech budu cist z tech socketu a posilat to do fronty. Fronta bude blokujici a mit jen urcitou maximalni velikost.

Vystaci na to 2 vlakna. No a ted problem je, ze nekteri by na to byli schopni udelat event loop, nebo na to napasovat Actor design pattern. A ruzne takove dalsi "fajnove" veci.

[Idris]

Nerád by som narušil plodnú diskusiu, ale skúste zadefinovať výraz "non-blocking" a potom opäť hladať definíciu asynchronicity...

Sidenote, je tu nejaký C/C++ kóder? Imho by vedel pekne vysvetlit, naco sa pouziva epoll a preco necakame na prijatie nejakych bajtov po sieti inym sposobom?

Sidenote2: Skusme rozobrat hypoteticku ulohu. Nakodit server, na ktory uploaduju nejake "pocitace" nejake subory a server ich iba uklada na disk. Pre predstavu skusme mat server s procesorom ktory zvladne duke nukem a ma mechanicky disk s rychlostou zapisu napriklad 10MB/s. A klientov dajme 10000 (nech to je 10k problem aspon . Samozrejme kazdy klient cez svoje wifi/bluetooth/idra posiela data rychlostou napriklad 500 bajtov za sekundu a ma za ulohu nahrat 1MB velky subor. Nech je sranda, klienti zacnu posielat subor naraz... (cielom je ukazat rozdiel medzi non-blocking a async. Jeden z nich je nutny na to, aby klient, ktory sa pripoji ako druhy, mohol zacat nieco dalsieho posielat a druhy je nutny, aby to dany cpu zvladol, respektive venoval sa aj robote a nielen "context switchingu")

Takze tech 10000 klientu, resp. 10000 socketu, budu obsluhovat v jedinem vlakne pres epoll. Protoze ten disk mi stejne umoznuje jenom sekvenci zapis, tak budu mit druhe vlakno, ktere bude mit frontu na zapisy. No a po bajtech budu cist z tech socketu a posilat to do fronty. Fronta bude blokujici a mit jen urcitou maximalni velikost.

Vystaci na to 2 vlakna. No a ted problem je, ze nekteri by na to byli schopni udelat event loop, nebo na to napasovat Actor design pattern. A ruzne takove dalsi "fajnove" veci.

Řešení přes epoll implikuje smyčku událostí.

[Zabanovaný Anonymní Troll]

Nerád by som narušil plodnú diskusiu, ale skúste zadefinovať výraz "non-blocking" a potom opäť hladať definíciu asynchronicity...

Sidenote, je tu nejaký C/C++ kóder? Imho by vedel pekne vysvetlit, naco sa pouziva epoll a preco necakame na prijatie nejakych bajtov po sieti inym sposobom?

Sidenote2: Skusme rozobrat hypoteticku ulohu. Nakodit server, na ktory uploaduju nejake "pocitace" nejake subory a server ich iba uklada na disk. Pre predstavu skusme mat server s procesorom ktory zvladne duke nukem a ma mechanicky disk s rychlostou zapisu napriklad 10MB/s. A klientov dajme 10000 (nech to je 10k problem aspon . Samozrejme kazdy klient cez svoje wifi/bluetooth/idra posiela data rychlostou napriklad 500 bajtov za sekundu a ma za ulohu nahrat 1MB velky subor. Nech je sranda, klienti zacnu posielat subor naraz... (cielom je ukazat rozdiel medzi non-blocking a async. Jeden z nich je nutny na to, aby klient, ktory sa pripoji ako druhy, mohol zacat nieco dalsieho posielat a druhy je nutny, aby to dany cpu zvladol, respektive venoval sa aj robote a nielen "context switchingu")

Takze tech 10000 klientu, resp. 10000 socketu, budu obsluhovat v jedinem vlakne pres epoll. Protoze ten disk mi stejne umoznuje jenom sekvenci zapis, tak budu mit druhe vlakno, ktere bude mit frontu na zapisy. No a po bajtech budu cist z tech socketu a posilat to do fronty. Fronta bude blokujici a mit jen urcitou maximalni velikost.

Vystaci na to 2 vlakna. No a ted problem je, ze nekteri by na to byli schopni udelat event loop, nebo na to napasovat Actor design pattern. A ruzne takove dalsi "fajnove" veci.

Řešení přes epoll implikuje smyčku událostí.

To si nemyslim, smycka udalosti je z podstaty jiny typ mechanismu nez epoll.

[Ladislav Zitka]

Pokusim se pridat z vlastni zkusenosti o co vlastne jde, jeste nez se asyn modely zacaly implementovat primo na urovni jazyka, asynchronni/event driven architektury uz existovali materializovane na urovni celych kup systemu, asi nejcenejsim zdrojem,ktery mi cele roky slouzil jako zdroj jak stavet asyn architektury mi byly tzv messaging patterns: https://www.enterpriseintegrationpatterns.com/

Prave tyto principy zde definovane, resp. pouze nektere z nich se zacaly integrovat primo do ruznych jazyku, tj. to, co se bezne pouzivalo na urovni integrace sluzeb/systemu, se zacalo pouzivat primo jako mechanismus vyvoje jednotlive sluzby, resp. jejich subkomponent. Skoda, ze kazdy jazyk si vytvoril ruzna jmena, ale principy jsou stale stejne, jen skocily o nejaky rad "dolu", coz je super. Co podle me je painful, protoze pouzivam ruzne jazyky je, ze kazdy jazyk si pouziva jen urcity subset z pattern a sklada z nich svoji cestu jak delat async programovani (Java, Angluar, NodeJs, haskell, etc.), ale neni to jeste na takove urovni, jako se to zvlada na urovni asyn sluzeb(jejich architektur), neni to dost genericke a prave enterprise integration patterns (messaging pattern) jsou krasnou sbirkou toho, co vsechno je mozne a jak by (podle me) mela async implementace vypadat, plnou adopci techto pattern, tj. vyberu si sam vhodny model.

Tak to jen takovy maly hit do zajimaveho tematu po ranu...

[Martin Sivák]

To si nemyslim, smycka udalosti je z podstaty jiny typ mechanismu nez epoll.

Epoll, select a příbuzní jsou.. chvilku počkejte... dramaticka pauza... asynchronní! Používají se ve smyčce, sledují několik zdrojů a vrací řízení programu, když nastane nějaká událost. Jedna smyčka obsluhuje několik klientů.

Synchronní verze by používala pro každé spojení jedno vlákno (aktor), které by čekalo na data pomocí blokujícího read(socket). Toto byl i standarní způsob zpracování klientů před příchodem "nových" verzí Apache, nginx, lighttpd a podobně.

[loblik]

Chtěl bych se naučit asynchronímu stylu programování. PRIMÁRNĚ mi jde o naučení se stylu, konceptu myšlení asynchronního programování. Hledám proto libovolnou, co možná nejvhodnější technologii, kde bych se tomuto naučil.

Pokud jde o C/C++ a Linux doporucuju:

man epoll
man timerfd_create
man signalfd
man inotify
a "self-pipe trick" .

[Idris]

Chtěl bych se naučit asynchronímu stylu programování. PRIMÁRNĚ mi jde o naučení se stylu, konceptu myšlení asynchronního programování. Hledám proto libovolnou, co možná nejvhodnější technologii, kde bych se tomuto naučil.

Pokud jde o C/C++ a Linux doporucuju:

man epoll
man timerfd_create
man signalfd
man inotify
a "self-pipe trick" .

NB: Na BSD (což zahrnuje macOS) je kqueue obsluhující síťové sockety, soubory i časovače. Windows (a některé Unixy) mají IO ports, to ale moc neznám.