Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: smonty 05. 10. 2019, 10:30:19

Název: Naučení se asynchronnímu programování
Přispěvatel: smonty 05. 10. 2019, 10:30:19
Ahoj,
(na úvod: před cca třemi lety jsem z oblasti synchronního programování vstoupil do vod čistého managementu. Snažím se ve volných chvílích učit nové věci ale co mi chybí a chtěl bych doplnit je asynchronní styl myšlení.)

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. Nejde tedy o technologii ale o získání daného myšlení. Záměrně zde neuvádím programovací jazyky ke kterým mám nejblíže, zajímá mne hlas lidu. Budu rád, když danou technologii rozjedu na Linuxu.

díky moc za rady :)
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PetrK 05. 10. 2019, 11:16:00
Asynschronni programovani je totalni srajda, je to dobre tak na klikatka na webu a podobne usecase. Na backend to budto nepatri vubec, nebo si musi dotycny citlive zvolit na co se mu to tam hodi, ale by default pouzivat synchronni programovani. Na backendu neprinasi asynchronni design zadne vyhody a je akorat problematicky. Vyjimkou snad muzou byt komponenty ktere musi zvladat tisice requestu za vterinu pochazejicich z Internetu a zaroven nesmi zrat moc zdroju, a takove komponenty jsou v enterprise velice vyjimecne.

Jak nekoho vidim, ze bastli backend a ze srandy to dela asynchronni, tak se mi otevira kudla v kapse.

Takze jestli se chces naucit asynchronni programovani, tak bez delat weby v node.js, tam presne to totiz patri. A abyses v tom bordelu co ti vznikne vyznal, tak tam samozrejme musis dat Redux. A neopovazuj se strkat asynchronni veci na backend, bo si te najdu a zbiju te.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 05. 10. 2019, 11:17:05
“Technologie,” která pomůže k pochopení principů, je kqueue. Na BSD (včetně macOS) to je přímo syscall, ale pro Linux existuje libkqueue se stejným API. Na vyšší úrovni pak GCD (libdispatch).
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Křišťan Surname 05. 10. 2019, 14:49:31
Já můžu za sebe doporučit (jako takovou ilustrující technologii) message brokery, například zeromq, konkrétně komunikační schéma push-pull, které se právě hodí k rozdělení úloh mezi velké množství asynchronně pracujících jednotek. Byl tu o tom na rootu docela pěkný seriál: https://www.root.cz/clanky/dalsi-moznosti-poskytovane-knihovnou-mq/#k12

Další náměty jsou zde: https://stackoverflow.com/questions/31248615/distributed-task-processing-using-zeromq
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Filip Jirsák 05. 10. 2019, 15:13:36
Když to vezmete podle používanosti jazyků, je JavaScript asi nejrozšířenější jazyk, kde je asynchronní programování od začátku integrální součástí jazyka. Spousta programátorů ho i kvůli tomu nenávidí… Dnes už se dá JavaScript používat i pro backend, osobně bych ho tam ale nepoužil na nic víc, než nějaké prototypy. Ale na webovém frontendu JavaScript kraluje a asynchronně se tam programuje odjakživa.

Pokud by vás zajímal spíš backend, tam se vyznám nejvíc v Javě. Pokud byste chtěl něco low-level, existuje projekt Netty (https://netty.io/) pro asynchronní síťovou komunikaci, staví se nad tím webové servery i klienti, streamovací servery a spousta dalších protokolů. Pokud něco na vyšší úrovni, osobně bych doporučil Micronaut Framework (https://micronaut.io/) – myslím, že je to Spring budoucnosti. Interně používá také Netty, interně má obsluhu požadavků asynchronní, ale umí to skrýt a pracovat v synchronním režimu.

Ale záleží, který směr vás zajímá – já jsem uvedl konkrétní implementace, ostatní uvedli koncepty jako message broker nebo fronta událostí. „Asynchronního“ toho na programování může být dost, ten pojem pokud vím neoznačuje nic konkrétního.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: listoper 05. 10. 2019, 18:31:23
V clojure je core.async. Myslim, ze je inspirovano go rutines. Jestli se nebojis lispu tak doporucuju.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Mirek Prýmek 05. 10. 2019, 20:09:47
Chtěl bych se naučit asynchronímu stylu programování.
Imho bys musel říct trochu konkrétněji, o co ti vlastně jde, co by ses chtěl naučit a proč.

Protože "asynchronní styl" může znamenat různý věci v různých kontextech. Většina z nich spolu nějak souvisí, ale není to totéž a pokud chceš radu, musíš to trochu líp specifikovat.

Jenom tak pro ilustraci, kolik různých věcí může "asynchronní styl" znamenat:

1. chci se v Pythonu naučit používat "async" a "await"
2. chci se naučit programovat multi-taskové aplikace ve FreeRTOSu a komunikaci mezi tasky
3. chci pochopit goroutiny a komunikaci mezi nimi
4. chci umět napsat multi-agentní (-servisovou, -komponentovou, distribuovanou...) aplikaci, kde jednotlivé komponenty jsou sice "synchronní", ale business logika celkového systému je z principu věci "asynchronní"
5. chci systému z předchozího bodu rozumět včetně nějaké té teorie kolem toho (všichni ti byzantští generálové apod.)
6. zajímá mě, jak se ty runtimy, na kterých ty "asynchronní jazyky" běží, píšou
7. zaujal mě actor model (nebo CSP, ...) a chtěl bych ho pochopit teoreticky i naučit se ho používat
atd. atp. ... možností je bambilion.

Záměrně zde neuvádím programovací jazyky ke kterým mám nejblíže, zajímá mne hlas lidu.
To mi moc nedává smysl. Ať už "asynchronní styl" znamená cokoli, dá se zrealizovat v každém rozumném jazyce, ale v každém trochu jinak. Základní principy jsou přenosné, ale nemá smysl se to učit v jazyce, který ti není blízký a nebudeš ho nikdy používat.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: gill 05. 10. 2019, 21:40:02
Asi bych začal s Javascriptem a oficiální dokumentací od Mozilly. Můžete si pohrát třeba s fetch API, zkoušet čisté Promisy i async/await. Snažte se používat jen API postavená na Promisech, dnes by to neměl být problém.

V Pythonu je to zkomplikované neexistencí jednotné event loop. await v Pythonu je v podstatě jen alias pro yield from. Na druhou stranu v async knihovnách v Pythonu existují standardní synchronizační primitiva jako asyncio.Queue a další https://docs.python.org/3/library/asyncio-sync.html, v JS musíte používat balíky třetích stran a kombinovat víc knihoven.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: gill 05. 10. 2019, 21:46:42
doporučuji starší videa Davida Beazleyho, kde implementuje vlastní event loop https://www.youtube.com/watch?v=MCs5OvhV9S4

https://www.youtube.com/watch?v=ZzfHjytDceU


následně implementoval i vlastní alternativu k asyncio, curio https://github.com/dabeaz/curio

která se sice neprosadila, ale inspirovala změny v standardním asyncio
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: gill 05. 10. 2019, 22:01:30
ale co mi chybí a chtěl bych doplnit je asynchronní styl myšlení.

to se naučíte jen praxí. Napište, jaký problém chcete asynchronně řešit, v jakém jazyce, a my vám poradíme konkrétněji.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: luvar 06. 10. 2019, 06:45:32
Nie som istý o akú úroveň asynchronicity Vám ide. Ja to vnímam tak, že je úroveň projektu (jedna binárka) a úroveň celkovej architektúry (komunikácia medzi komponentami samostatne bežiacimi). Skúsim pridať môj názor pre obe.

Osobne by som odporučil (pre low level, programátorský pohľad) knižku https://learnyousomeerlang.com/ (https://learnyousomeerlang.com/) a teda jazyk erlang.

Je v každom prípade ale nutné si uvedomiť rozdiel medzi "non-blocking" a "async". Myslim, ze to bolo pekne vysvetlene vo videu tuna: https://youtu.be/E3s5f-JF8z4?t=526 (https://youtu.be/E3s5f-JF8z4?t=526) Je to z prednasky o https://r2dbc.io/ (https://r2dbc.io/), čo je reaktívny, non-blocking drajver k databázam. V každom prípade takýto štýl programovania má zmysel pri spoločnostiach a produktoch o veľkosti "netflix". Inde sa to nezaplatí aktuálne.

Ďalšou kategóriou ale môže byť vzdelávanie v "asynchrónnych" mikroservisoch, kde sa dá nahliadať na komunikáciu medzi službami, ktorá býva zväčša asynchrónna. Tam je vhodné hodiť do googlu napríklad "CQRS", alebo "event sourcing", prípadne spomenuté zeromq, či architektúry používajúce kafku alebo pulsar, či rabbitmq.

Všeobecne vhodným zdrojom praktických príbehov býva https://www.infoq.com/ (https://www.infoq.com/) portál (a zvačša tam nie sú prešlapy, ako v bežných časopisoch, kde napíšu občas do očí kričiacu koninu).
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PanVP 06. 10. 2019, 22:48:47
Jak nekoho vidim, ze bastli backend a ze srandy to dela asynchronni, tak se mi otevira kudla v kapse.

Přehnaně asynchronni aplikace se často plní omáčkou, zhoršuje se její čitelnost a bezpečnost.
IMHO je skutečně dobré uvážit, co dělat synchronně a co ne.
Sám jsem se dostal do krásné pasti, v zápalu "jééé to je super", jsem tak napsal jednu verzi aplikace.
Byla delší, vypadala hustě, kolega jí nerozuměl. Měl jen jednu vadu, občas sebou řízla a nedokázal jsem zjistit proč se to vlastně stalo. Nakonec bylo jednodušší hromady kódu vyházet a asynchronně dělat skutečně jen rozumné minimum.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: gill 07. 10. 2019, 09:31:00
Byla delší, vypadala hustě, kolega jí nerozuměl.

s async/await se dá psát stejně stručně jako s vlákny. Většinou stručněji, nehrozí data races a jiné chyby.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: gill 07. 10. 2019, 09:41:32
A neopovazuj se strkat asynchronni veci na backend, bo si te najdu a zbiju te.

neřešil jsi tu nedávno long polling v Javě? S asynchronní technologií to je trivialita, na kterou by ses nemusel ptát na foru. To stejné sockety.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Mirek Prýmek 07. 10. 2019, 11:55:50
Byla delší, vypadala hustě, kolega jí nerozuměl.
s async/await se dá psát stejně stručně jako s vlákny. Většinou stručněji
Stručnost je pravda. Zároveň ale potenciální nesrozumitelnost kolegovi je taky realita. Obávám se, že developerů, kteří opravdu chápou, co async/await dělá, bude relativně málo. Obávám se, že velká část těch, kdo async/await umí použít, se budou jenom řídit takovými těmi pravidly palce typu "když je uvnitř někde await, funkce musí být async" apod.

nehrozí data races a jiné chyby.
V jakém smyslu? V porovnání s čím? Jaký přesně mechanismus zaručuje, že k nim nemůže dojít?

---
Konkrétně třeba pro Python: zápis je pěkný, na první pohled čitelný. Reasoning o chování většího kódu je ale pořád složitější než u "jednovláknového" programu (čemuž se dost dobře nedá vyhnout, není to tak úplně chyba Pythonu). Dost katastrofa je to ale na úrovni infrastruktury: Pokud chci async/await použít, musím mít úplně jiné, "async" knihovny. A ty jsou oproti jejich starším "sync" variantám většinou daleko víc zabugované nebo nedodělané. Navíc neustále budu narážet na problém "červeného a modrého světa" [1], často se stane, že kvůli tomu nepůjde dobře zrealizovat návrh, který jsem měl namyšlený - že je tam problém si všimnu až při psaní, dopředu se to odhaduje fakt těžko. Problémy typu "aha, __init__ vlastně nemůže být async! Doprčic!"


[1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 07. 10. 2019, 12:44:46
Jak nekoho vidim, ze bastli backend a ze srandy to dela asynchronni, tak se mi otevira kudla v kapse.
Přehnaně asynchronni aplikace se často plní omáčkou, zhoršuje se její čitelnost a bezpečnost.
Od toho jsou korutiny, aby synchronně vypadající kód běžel asynchronně.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 07. 10. 2019, 12:49:57
Byla delší, vypadala hustě, kolega jí nerozuměl.
s async/await se dá psát stejně stručně jako s vlákny. Většinou stručněji
Obávám se, že developerů, kteří opravdu chápou, co async/await dělá, bude relativně málo.
To ale není chyba technologie/konceptu, že to lidi nechápou. Takových témat se najde mnohem víc, třeba “the M word” ve FP.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Mirek Prýmek 07. 10. 2019, 12:55:16
To ale není chyba technologie/konceptu, že to lidi nechápou. Takových témat se najde mnohem víc, třeba “the M word” ve FP.
Jak se to veme. Já moc nemám rád koncepty, které něco relativně složitého zabalí tak, že to vypadá jednoduše, člověk může nabýt dojmu, že tomu rozumí, ale ve skutečnosti nerozumí a tímpádem právě není schopnej toho reasoningu* nad kódem. Proto osobně async/await nemám rád. Daleko lepší mi přijdou ty korutiny, to je koncept, kterej nic neschovává, člověk na první pohled vidí, co se tam děje. A ještě lepší jsou úplně ne-kooperativní procesy v Erlangu (korutiny v Go, alespoň donedávna, byly částečně kooperativní, IIRC - přepínalo se jenom na některých místech).


* sorry za opakování tohodle slova, ale přijde mi výstižný a neznám podobně dobrý český ekvivalent
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 07. 10. 2019, 13:30:20
To ale není chyba technologie/konceptu, že to lidi nechápou. Takových témat se najde mnohem víc, třeba “the M word” ve FP.
Jak se to veme. Já moc nemám rád koncepty, které něco relativně složitého zabalí tak, že to vypadá jednoduše, člověk může nabýt dojmu, že tomu rozumí, ale ve skutečnosti nerozumí a tímpádem právě není schopnej toho reasoningu* nad kódem. Proto osobně async/await nemám rád. Daleko lepší mi přijdou ty korutiny, to je koncept, kterej nic neschovává, člověk na první pohled vidí, co se tam děje. A ještě lepší jsou úplně ne-kooperativní procesy v Erlangu (korutiny v Go, alespoň donedávna, byly částečně kooperativní, IIRC - přepínalo se jenom na některých místech).


* sorry za opakování tohodle slova, ale přijde mi výstižný a neznám podobně dobrý český ekvivalent
Vždyť async/await jsou právě taky jen korutiny, jen se zbytečně složitou syntaxí (proto to tolik lidí mate). Právě Go má v podstatě to samé, ale transparentně.

BTW scheduler v Go je kooperativní doposud, jede nad kqueue/IO ports apod. podle OS.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: gill 07. 10. 2019, 15:18:44
Goroutiny nejsou korutiny. Korutiny běží v jednom vlákně.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 07. 10. 2019, 16:23:09
Goroutiny nejsou korutiny. Korutiny běží v jednom vlákně.
Gorutiny taky, když máš jen jedno jádro. Je to úplně to samé, až na jedno písmenko.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: gill 07. 10. 2019, 16:28:26
nehrozí data races a jiné chyby.
V jakém smyslu? V porovnání s čím? Jaký přesně mechanismus zaručuje, že k nim nemůže dojít?
v provnání s vlákny
Dost katastrofa je to ale na úrovni infrastruktury: Pokud chci async/await použít, musím mít úplně jiné, "async" knihovny. A ty jsou oproti jejich starším "sync" variantám většinou daleko víc zabugované nebo nedodělané.

to je pravda, v tom jsou lepší jazyky, kde je asynchronní vše. Částečné řešení je volání sync variant blokujících funkcí v threadpoolu. https://docs.python.org/3/library/asyncio-eventloop.html#executing-code-in-thread-or-process-pools . Většinou si vystačíte s použitím čistě async funkcí jen pro socketovou komunikaci a ostatními IO funkcemi volanými v threadpoolu. I rozšiřující "async" knihovny například pro přístup k DB jsou většinou implementovány obalením sync funkcí run_in_executor. Další problém je existence několika nekompatibilních základních async knihoven (asyncio, trio, curio). Existuje snaha sjednotit API minimálně mezi trio a asyncio. Dost rozšiřujících knihoven podporuje obojí.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Mirek Prýmek 07. 10. 2019, 16:52:14
Vždyť async/await jsou právě taky jen korutiny, jen se zbytečně složitou syntaxí (proto to tolik lidí mate). Právě Go má v podstatě to samé, ale transparentně.
Asi podle toho, na jake urovni se na to divas. Async/await je hlavne cukr pro futures, zatimco goroutiny spis davaji pocit plne oddelenych vlaken provadeni - jako plnohodnotna OS vlakna. Implementacne to muze byt dost podobne, hlavne na urovni event loopu, ale ten koncept jako takovy je imho dost jiny - async/await je matouci a otravne, gorutiny jsou naprosto v pohode.

BTW scheduler v Go je kooperativní doposud, jede nad kqueue/IO ports apod. podle OS.
Dik. Mel jsem matny pocit, ze jsem nekde cetl, ze s tim cosi v posledni dobe delali. Bud se pletu, nebo to mozna byl nejaky plan pro Go 2? Nevim.

v provnání s vlákny
Ok. V porovnani s vlakny ale imho async/await samo o sobe negarantuje nemoznost race conditions. Porad je tam nejake prepinani kontextu, ke kteremu pri trose fantazie muze dojit v nevhodny okamzik. Tim spis, cim vic k tomu prepinani dochazi. Jestli je tam nejaky vyrazny rozdil oproti vlaknum, tak prave v tom, ze se prepina jenom v urcite okamziky, takze k race condition nemusi vubec nikdy dojit. To ale neni garance, to je (vicemene) nahoda, coz je mozna jeste horsi...

v tom jsou lepší jazyky, kde je asynchronní vše.
Bez diskuse. Vubec nechapu, proc Python touhle cestou nesel. Imho si tim pekne nabehl na vidle a co je horsi, potahne si tuhle zatez ssebou jeste pekne dlouho, protoze se z toho dost dobre ted uz neda vybrednout :(

Částečné řešení je volání sync variant blokujících funkcí v threadpoolu. https://docs.python.org/3/library/asyncio-eventloop.html#executing-code-in-thread-or-process-pools . Většinou si vystačíte s použitím čistě async funkcí jen pro socketovou komunikaci a ostatními IO funkcemi volanými v threadpoolu. I rozšiřující "async" knihovny například pro přístup k DB jsou většinou implementovány obalením sync funkcí run_in_executor.
Jo, ale to je strasnej opruz. Odstranuje to tu jedinou potencialni vyhodu async/await - prehlednost kodu. Dalsi problem je, ze v Pythonni implementaci doted chybi zakladni primitiva k tomu, aby to mohl clovek opravdu vyuzivat. Kdyz clovek zna Erlang s jeho linky, monitory, signaly, supervizory, ... tak si v Pythonu pripada, jako by mu nekdo urizl ruku, vytrhl jazyk, zavazal oci a jeste ho jenom tak jakoze ze srandy pichal spendlikama pod nehty...

Další problém je existence několika nekompatibilních základních async knihoven (asyncio, trio, curio). Existuje snaha sjednotit API minimálně mezi trio a asyncio. Dost rozšiřujících knihoven podporuje obojí.
No to je uplnej pruser, kterej jsem ani nezminil, abych se nerozcilil vic nez je nutne :) Par let zpatky to byla vylozene tragedie. Dneska nastesti asyncio hodne dobrych featur z ostatnich implementaci pohltilo a jelikoz je ve standardni knihovne, nejspis do budoucna vyhraje. Takze uz to takova traga neni. Nejlepsi je proste imho smirit se s asyncio.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Mirek Prýmek 07. 10. 2019, 17:00:09
Mel jsem matny pocit, ze jsem nekde cetl, ze s tim cosi v posledni dobe delali.
Mozna to bylo tohle https://github.com/golang/go/issues/24543 ? (Zatim?) jenom proposal.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 07. 10. 2019, 17:12:53
Vždyť async/await jsou právě taky jen korutiny, jen se zbytečně složitou syntaxí (proto to tolik lidí mate). Právě Go má v podstatě to samé, ale transparentně.
Asi podle toho, na jake urovni se na to divas. Async/await je hlavne cukr pro futures, zatimco goroutiny spis davaji pocit plne oddelenych vlaken provadeni - jako plnohodnotna OS vlakna. Implementacne to muze byt dost podobne, hlavne na urovni event loopu, ale ten koncept jako takovy je imho dost jiny - async/await je matouci a otravne, gorutiny jsou naprosto v pohode.
Ano, myslím na implementační úrovni, kde je naprostá shoda (akorát to teda nijak nesouvisí se smyčkou událostí, jde jen o kooperativní scheduler). Ani neplatí, jak tu chybně zaznělo, že "korutiny" běží jen v jednom vlákně (to může napsat jen javascriptař, ten víc vláken nezná, ale o srandajazycích se snad nebavíme :) ).
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 07. 10. 2019, 17:16:43
BTW scheduler v Go je kooperativní doposud, jede nad kqueue/IO ports apod. podle OS.
Dik. Mel jsem matny pocit, ze jsem nekde cetl, ze s tim cosi v posledni dobe delali. Bud se pletu, nebo to mozna byl nejaky plan pro Go 2? Nevim.
Ne ne, akorát přidali přepínání korutin i k volání funkcí, takže když nějaká gorutina běží moc dlouho a volá funkci, která není async, tak se stejně může vykonávání přerušit a scheduler může přepnout kontext. To je ale pořád čistě kooperativní.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Mirek Prýmek 07. 10. 2019, 17:21:50
Goroutiny nejsou korutiny. Korutiny běží v jednom vlákně.
Gorutiny taky, když máš jen jedno jádro. Je to úplně to samé, až na jedno písmenko.
Tohle je uz vylozene hnidopisstvi, ale nevim, jestli je dobry tvrdit, ze je to to same. Konceptualne ano, implementacne spis ne. Minimalne je rozdil v tom, ze goroutiny se muzou prepinat v ruzne okamziky (u soucasne implementace napriklad s kazdym volanim funkce AFAIK), zatimco u coroutin se predpoklada explicitni "spoluprace" programatora nejakym zpusobem typu yield apod.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 07. 10. 2019, 17:26:03
Mel jsem matny pocit, ze jsem nekde cetl, ze s tim cosi v posledni dobe delali.
Mozna to bylo tohle https://github.com/golang/go/issues/24543 ? (Zatim?) jenom proposal.
Jo, to má milestone 1.14, první odklon od kooperativity.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Mirek Prýmek 07. 10. 2019, 17:26:39
akorát to teda nijak nesouvisí se smyčkou událostí, jde jen o kooperativní scheduler
Myslel jsem to tak, ze vsechny tyhle srandy ve finale na nejnizsi urovni znamenaji to samy - rozkouskovani linearnio kodu na nejake chunky, kterym se v nejakem loopu postupne prideluje cas behu. Potencialne na vic jadrech/vlaknech, ale to na tom nic nemeni.

(to může napsat jen javascriptař, ten víc vláken nezná, ale o srandajazycích se snad nebavíme :) ).
No tak on to prave nezna ani Python, v tom je cast toho celyho pruseru :)

Ne ne, akorát přidali přepínání korutin i k volání funkcí
To jo, ale to uz bylo davno. Ted jsem koukal, ze Go 1.2.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 07. 10. 2019, 17:28:54
Goroutiny nejsou korutiny. Korutiny běží v jednom vlákně.
Gorutiny taky, když máš jen jedno jádro. Je to úplně to samé, až na jedno písmenko.
Tohle je uz vylozene hnidopisstvi, ale nevim, jestli je dobry tvrdit, ze je to to same. Konceptualne ano, implementacne spis ne. Minimalne je rozdil v tom, ze goroutiny se muzou prepinat v ruzne okamziky (u soucasne implementace napriklad s kazdym volanim funkce AFAIK), zatimco u coroutin se predpoklada explicitni "spoluprace" programatora nejakym zpusobem typu yield apod.
Právěže to je shodné implementačně, třeba zrovna v C# funguje scheduler úplně stejně.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Mirek Prýmek 07. 10. 2019, 17:37:31
Právěže to je shodné implementačně, třeba zrovna v C# funguje scheduler úplně stejně.
Nevim, jestli jsme si uplne porozumeli, ale to je jedno, je to prkotina, nechme to byt :)
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 07. 10. 2019, 17:42:39
akorát to teda nijak nesouvisí se smyčkou událostí, jde jen o kooperativní scheduler
Myslel jsem to tak, ze vsechny tyhle srandy ve finale na nejnizsi urovni znamenaji to samy - rozkouskovani linearnio kodu na nejake chunky, kterym se v nejakem loopu postupne prideluje cas behu. Potencialne na vic jadrech/vlaknech, ale to na tom nic nemeni.

(to může napsat jen javascriptař, ten víc vláken nezná, ale o srandajazycích se snad nebavíme :) ).
No tak on to prave nezna ani Python, v tom je cast toho celyho pruseru :)

Ne ne, akorát přidali přepínání korutin i k volání funkcí
To jo, ale to uz bylo davno. Ted jsem koukal, ze Go 1.2.
Jo, ideálně v loopu na úrovni jádra, proto to je vlastně jen obal okolo kqueue, IO ports etc. Těch víc vláken pak funguje na principu GCD, kde se korutiny přidělují vláknům z poolu, aby nedocházelo ke drahému přepínání kontextu. Technicky to je vlastně brilantní, pamatuju časy, kdy jsem psal nad kqueue přímo, to ještě nebylo ani Go, ani GCD, a Java ještě byla novinkou (ovšem bez NIO). Neuvěřitelné, jaké možnosti otevírá jeden syscall.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PetrK 07. 10. 2019, 22:46:14
Zrovna jsem psal takovou jednu servisu v Jave ve Springu a rozhodoval jsem se jestli nektere casti kodu neudelt asynchronne pres Futures a nove thready. Ta resena uloha na to byla jako delana. Uz jsem to tak mel napsane a zjistil jsem, ze mi to prinese vice problemu nez uzitku. Nakonec jsem nasel zpusov jak to udelat normalnim sekvencnim kodem s fixne definovanymi worker thready a je to lepsi. A tak je to dycky. Nejhorsi je, kdyz nejaky jazyk, jako je C#, obsahuje 100 ruznych pitchovin featur. Pak vznikne problem typu "Kdyz mas kladivko, tak se vsechno jevi jako hrebik", a mas chut to vsechno pouzivat, ackoliv to akorat zvysuje komplikovanost kodu.

Ja se treba priznam, ze casto i dost vaham nad uzitecnosti Streamu (monady). Mnohokrat mi prijde pouziti Foreahe mnohem praktictejsi a prehlednejsi. Dodnes z pameti nevim, jak ve Streamu napr. udelat Group By nad Mapou a musim cumet do Googlu.

Po tisicateprve, ti lidi co to takhle ten synchronni design v historii pocitacu vymysleli, nebyli debilove nebo idioti.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 07. 10. 2019, 22:50:31
Zrovna jsem psal takovou jednu servisu v Jave ve Springu a rozhodoval jsem se jestli nektere casti kodu neudelt asynchronne pres Futures a nove thready. Ta resena uloha na to byla jako delana. Uz jsem to tak mel napsane a zjistil jsem, ze mi to prinese vice problemu nez uzitku. Nakonec jsem nasel zpusov jak to udelat normalnim sekvencnim kodem s fixne definovanymi worker thready a je to lepsi. A tak je to dycky. Nejhorsi je, kdyz nejaky jazyk, jako je C#, obsahuje 100 ruznych pitchovin featur. Pak vznikne problem typu "Kdyz mas kladivko, tak se vsechno jevi jako hrebik", a mas chut to vsechno pouzivat, ackoliv to akorat zvysuje komplikovanost kodu.

Ja se treba priznam, ze casto i dost vaham nad uzitecnosti Streamu (monady). Mnohokrat mi prijde pouziti Foreahe mnohem praktictejsi a prehlednejsi. Dodnes z pameti nevim, jak ve Streamu napr. udelat Group By nad Mapou a musim cumet do Googlu.

Po tisicateprve, ti lidi co to takhle v historii pocitacu vymysleli, nebyli debilove nebo idioti.
Streamy jsou úlet.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PanVP 07. 10. 2019, 22:56:42
"Kdyz mas kladivko, tak se vsechno jevi jako hrebik"

+1000 bludišťáků
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PetrK 07. 10. 2019, 23:11:40
Jo a kdyz uz jsem se tak rozjel, tak bych chtel jeste rict, ze me dost casto sere i ten foreach a radeji bych pouzival obycejny for, kdyz to jde :D

Jak vidite, jsem konzervativni programator.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PanVP 07. 10. 2019, 23:12:52
vaham nad uzitecnosti Streamu (monady)
Streamy jsou úlet.

https://mikhail.io/2018/07/monads-explained-in-csharp-again/ (https://mikhail.io/2018/07/monads-explained-in-csharp-again/)

To vysvětlení je celkem pěkné.
Ovšem, popravdě, když se po roce koukám na svůj kód, tak si říkám, co jsem tím chtěl vlastně říct?
No a nejsem si jistý, jestli zrovna tohle zlepšuje čitelnost zápisu.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: gill 08. 10. 2019, 10:17:14
vaham nad uzitecnosti Streamu (monady)
Streamy jsou úlet.

https://mikhail.io/2018/07/monads-explained-in-csharp-again/ (https://mikhail.io/2018/07/monads-explained-in-csharp-again/)

To vysvětlení je celkem pěkné.
Ovšem, popravdě, když se po roce koukám na svůj kód, tak si říkám, co jsem tím chtěl vlastně říct?
No a nejsem si jistý, jestli zrovna tohle zlepšuje čitelnost zápisu.

v C# pro to není syntax. Jsou jazyky, kde nemusíš psát  .Bind ručně.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: kimec 08. 10. 2019, 10:33:49
Po tisicateprve, ti lidi co to takhle ten synchronni design v historii pocitacu vymysleli, nebyli debilove nebo idioti.
Ano, tento problem je prinajmensom znamy uz od polovice minuleho storocia 1963 Timesharing: A Solution to Computer Bottlenecks (http://"https://www.youtube.com/watch?v=Q07PhW5sCEk"). (zvyraznene zamerne).

Ide v podstate iba o dve veci:

Najprv stacili programy/procesy, potom prisli vlakna, potom prisli callbacky a lahke vlakna. Uz len samotne kontinuacie boli znovuvynajdene niekolko krat od 60tych rokov (http://"https://homepages.inf.ed.ac.uk/wadler/papers/papers-we-love/reynolds-discoveries.pdf")... Kazde riesnie ma svoje vyhody a nevyhody. Ale v podstate sa zongluje iba s ergonomiou a efektivitou.

Ci riesim dany problem callbackmi, Promismi, event loopom, co mi poskytuje moj OS (BSD, Linux, Windows), ci ma moj languge runtime userspace scheduler, ktory vytazi CPU bez context switchov a pouziva krajsiu abstrakciu v podobe kontinuacie delimitovanej alebo inej, ci za mna kompiler urobi CPS transformaciu alebo nie, problem je stale ten isty... co robit, ked CPU nema co robit, lebo caka na IO.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: kimec 08. 10. 2019, 10:51:26
Po tisicateprve, ti lidi co to takhle ten synchronni design v historii pocitacu vymysleli, nebyli debilove nebo idioti.
Ano, tento problem je prinajmensom znamy uz od polovice minuleho storocia 1963 Timesharing: A Solution to Computer Bottlenecks (http://"https://www.youtube.com/watch?v=Q07PhW5sCEk"). (zvyraznene zamerne).

Ide v podstate iba o dve veci:
  • ergonomia abstrakcie, s ktorou naraba programator
  • efektivita z pohladu vyuzitia procesora

Najprv stacili programy/procesy, potom prisli vlakna, potom prisli callbacky a lahke vlakna. Uz len samotne kontinuacie boli znovuvynajdene niekolko krat od 60tych rokov (http://"https://homepages.inf.ed.ac.uk/wadler/papers/papers-we-love/reynolds-discoveries.pdf")... Kazde riesnie ma svoje vyhody a nevyhody. Ale v podstate sa zongluje iba s ergonomiou a efektivitou.

Ci riesim dany problem callbackmi, Promismi, event loopom, co mi poskytuje moj OS (BSD, Linux, Windows), ci ma moj languge runtime userspace scheduler, ktory vytazi CPU bez context switchov a pouziva krajsiu abstrakciu v podobe kontinuacie delimitovanej alebo inej, ci za mna kompiler urobi CPS transformaciu alebo nie, problem je stale ten isty... co robit, ked CPU nema co robit, lebo caka na IO.

Zmrsene odkazy:

https://www.youtube.com/watch?v=Q07PhW5sCEk

https://homepages.inf.ed.ac.uk/wadler/papers/papers-we-love/reynolds-discoveries.pdf
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Martin Sivák 08. 10. 2019, 10:58:39
Ja se treba priznam, ze casto i dost vaham nad uzitecnosti Streamu (monady). Mnohokrat mi prijde pouziti Foreahe mnohem praktictejsi a prehlednejsi. Dodnes z pameti nevim, jak ve Streamu napr. udelat Group By nad Mapou a musim cumet do Googlu.

Co mají Streamy s monádami? Prostě normální funkce vyššího řádu.

A ručně se to copak implementuje snáz? Mapa, group by funkce, funkce na agregaci.. Taky se dívám do dokumentace, když to píšu, ale mnohem častěji to pak čtu. A ta Stream varianta je pro čtení mnohem přehlednější.

Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 08. 10. 2019, 11:54:18
Ja se treba priznam, ze casto i dost vaham nad uzitecnosti Streamu (monady). Mnohokrat mi prijde pouziti Foreahe mnohem praktictejsi a prehlednejsi. Dodnes z pameti nevim, jak ve Streamu napr. udelat Group By nad Mapou a musim cumet do Googlu.
Co mají Streamy s monádami? Prostě normální funkce vyššího řádu.
  ::)
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Jiří Havel 08. 10. 2019, 12:16:07
Ja se treba priznam, ze casto i dost vaham nad uzitecnosti Streamu (monady). Mnohokrat mi prijde pouziti Foreahe mnohem praktictejsi a prehlednejsi. Dodnes z pameti nevim, jak ve Streamu napr. udelat Group By nad Mapou a musim cumet do Googlu.

Co mají Streamy s monádami? Prostě normální funkce vyššího řádu.
Nic moc, krom toho že streamy jsou monády. :D Akorát "bind" je přejmenovaný na "flatMap".
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Martin Sivák 08. 10. 2019, 14:42:49
Co mají Streamy s monádami? Prostě normální funkce vyššího řádu.
Nic moc, krom toho že streamy jsou monády. :D Akorát "bind" je přejmenovaný na "flatMap".

A to je v kontextu Javy a asynchronního programování důležité proč? Je to pojem z matematické teorie kategorií, který pro běžného programátora není naprosto důležitý. Kdejaká operace splňuje definici grupy nebo monoidu, ale použivá se to tak akorát při formálních důkazech a analýzách algoritmů.

V Pythonu se to samé dělá přes List comprehensions a itertools, v C# pomocí LINQ. V Javě holt syntaxe vyšla jak vyšla. Streamy jsou totiž hlavně užitečnými abstrakcemi nad často se opakujícími operacemi. Nikdo nad nimi matematické důkazy nedělá.

Takže dejte pokoj s monádami, je to v kontextu diskuze nepodstatný a neužitečný detail.



Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Jiří Havel 08. 10. 2019, 16:02:43
A to je v kontextu Javy a asynchronního programování důležité proč? Je to pojem z matematické teorie kategorií, který pro běžného programátora není naprosto důležitý. Kdejaká operace splňuje definici grupy nebo monoidu, ale použivá se to tak akorát při formálních důkazech a analýzách algoritmů.
...
Citace
Vy jste se ptal "Co mají Streamy s monádami?" ;)

Běžný programátor to možná _nazývá_ jinak, ale _používá_ to naprosto běžně. Jestli je nějaká operace asociativní je důležité, pokud chci dělat třeba paralelní redukci. Jednotkový prvek mi zjednoduší api a počáteční podmínky. A ejhle, používám monoidy a to jsem k žádnému důkazu ani nečichl.

Máte nějaký problém s tím, že tyhle všudypřítomné struktury budeme nazývat stejně jako v matice?
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: gill 08. 10. 2019, 16:06:07
Takže dejte pokoj s monádami, je to v kontextu diskuze nepodstatný a neužitečný detail.

téměř každá diskuze, do které se zapojí Mirek Prýmek a Idris skončí u monád.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Mirek Prýmek 08. 10. 2019, 16:16:52
téměř každá diskuze, do které se zapojí Mirek Prýmek a Idris skončí u monád.
Tentokrát jsme v tom ale naprosto nevinně :)
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: gill 08. 10. 2019, 16:19:27
téměř každá diskuze, do které se zapojí Mirek Prýmek a Idris skončí u monád.
Tentokrát jsme v tom ale naprosto nevinně :)

To ale není chyba technologie/konceptu, že to lidi nechápou. Takových témat se najde mnohem víc, třeba “the M word” ve FP.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: hawran diskuse 08. 10. 2019, 16:42:53
Takže dejte pokoj s monádami, je to v kontextu diskuze nepodstatný a neužitečný detail.

téměř každá diskuze, do které se zapojí Mirek Prýmek a Idris skončí u monád.
:) ;) :D ;D
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Mirek Prýmek 08. 10. 2019, 16:45:52
To ale není chyba technologie/konceptu, že to lidi nechápou. Takových témat se najde mnohem víc, třeba “the M word” ve FP.
Tos ale blbě pochopil, tím Idris myslel monomorfismus ;)
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: hasikada 08. 10. 2019, 18:10:46
Něco málo z pravěku, zajímavý byl Symbian OS, to je ten systém co se používal na prvních Nokia smartphonech. Symbian vychází ze systému EPOC. Systém se používal na organizérech firmy Psion někdy od roku 1991. V té době nabízel preemptivní multitasking, grafické rozhraní, aplikace (database, word processor, spreadsheet) na CPU 4.7 Mhz a 256 KB RAM. Architektura EPOCu byla inspirována systémem VAX/VMS, 70 léta.

Jádrém návrhu bylo asychronní nátura aplikace. Taková typická mobilní aplikace většinu času čeká na událost (stisk klávesy, příchozí SMS, příchozí mail). Používál se Active Object návrhový vzor. Vzor zahrnuje Active Scheduler a Active Object. Scheduler je smyčka která čeka na signál nebo spravuje active objecty. Active  Object zapouzdřuje volání asynchronní metody a zpracování výsledku. Asynchronní metoda je operace nad resourcem, např žádost o notifikaci na příchozí SMS, resourcem je příchozí SMS. Resource spravuje systémovy server (Windows server, Telephony server, Network server.). Jakmile server zpracuje požadavek, server vyšle signal clientovi, active scheduler se probudí, najde správny active object a zpracuje výsledek. Asynchronní metoda je tedy client-server request, podobně jako REST. I samotné UI eventy jsou implementovaný jako active object, který donekonečna žádá o uživatelský vstup. Aplikační framework poskytoval plnou podporu pro asynchronní volání a řesil tyto problemy:


Operace nad resourcem byly serializované, tzn např aplikace mohla vyvolat pouze jednu žádost o stisk klávesy v čase, až se zpracoval výsledek, aplikace mohla žádat znovu. Měli to tehdy pěkně vyřešené, od začátku navrhli pěkný design, takže orientovat se v ruzných části systému bylo jednoduché. Ve výsledku Active Object vzor je kooperativní multitasking v aplikaci (lehké vlákna).

Mrkni na dnešní Event Sourcing, CQRS, Eventual consistency. Problémy jsou stále stejné. Např vytvoření objednávky v systému, vytvoří se událost, událost se vloží do fronty, z fronty událost vybere nějaky microservice, a vytvoří objednávku ve své databázi. Client pošle dotaz na vytvořenou objednávku, ale objednávka není ještě uložena. Client pošle dotaz znovu, objednávka stále není vytvořena a řekněmě, že už postráda smysl. Co teď? Je operace idempotentní? Zrušit? Jak? Kompenzační událost, která zruší předchozí událost? Jak? Událost je pravděbodobně stále ve frontě a čeká na zpracování. Takže objednávka muže existovat než příjde kompenzační událost na řadu?
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Mirek Prýmek 08. 10. 2019, 18:17:41
Taková typická mobilní aplikace většinu času čeká na událost
Myslím, žes celkem dobře ilustroval, jak je pojem "asynchronní" rozbředlý, takže ve finále celkem k ničemu. To, co popisuješ, by klidně někdo mohl místo "asynchronní", nazvat spíš "event-driven"...

Samotný pojem "asynchronní" znamená všechno a nic. Je potřeba říct, v jakým kontextu a na jaké úrovni ho mám na mysli, jinak je z toho jenom zmatení...
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 08. 10. 2019, 21:16:56
To ale není chyba technologie/konceptu, že to lidi nechápou. Takových témat se najde mnohem víc, třeba “the M word” ve FP.
Tos ale blbě pochopil, tím Idris myslel monomorfismus ;)
Tak jasně, kdo chce psát asynchronní kód, musí tam dát monomorfismus. A kdo nemá monomorfismus, tak ať tam dá nějakej jinej morfismus. A kdo nemá žádnej morfismus, tak ať tam nedává nic  ;)
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PetrK 08. 10. 2019, 21:55:22
Taková typická mobilní aplikace většinu času čeká na událost
Myslím, žes celkem dobře ilustroval, jak je pojem "asynchronní" rozbředlý, takže ve finále celkem k ničemu. To, co popisuješ, by klidně někdo mohl místo "asynchronní", nazvat spíš "event-driven"...

Samotný pojem "asynchronní" znamená všechno a nic. Je potřeba říct, v jakým kontextu a na jaké úrovni ho mám na mysli, jinak je z toho jenom zmatení...

Ja si myslim, ze asyncrhonni znamena neco konkretniho a docela presne. Znamena to totiz, ze neco neni neni synchronni. A jak neco neni synchronni, tak je treba dycky zbystrit, protoze se s tim bude jistojiste delat blbeji, nez kdyby to bylo syncrhonni 8) :D
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PetrK 08. 10. 2019, 22:00:46
Mrkni na dnešní Event Sourcing, CQRS, Eventual consistency. Problémy jsou stále stejné. Např vytvoření objednávky v systému, vytvoří se událost, událost se vloží do fronty, z fronty událost vybere nějaky microservice, a vytvoří objednávku ve své databázi. Client pošle dotaz na vytvořenou objednávku, ale objednávka není ještě uložena. Client pošle dotaz znovu, objednávka stále není vytvořena a řekněmě, že už postráda smysl. Co teď? Je operace idempotentní? Zrušit? Jak? Kompenzační událost, která zruší předchozí událost? Jak? Událost je pravděbodobně stále ve frontě a čeká na zpracování. Takže objednávka muže existovat než příjde kompenzační událost na řadu?

Tady jsi krasne ukazal, jak se muzes zamotat do Asynchronniho programovani. V synchronnim systemu zpracovani objednavek na takovy problem nenarazis. Tak je to dycky s tim asynchronnim udalostmi rizenem programovani. Myslis si ze sis neco ulehcil, ale pritom neulehcil, protoze musis resit takoveto filozoficke problemy.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Mirek Prýmek 09. 10. 2019, 10:13:13
Ja si myslim, ze asyncrhonni znamena neco konkretniho a docela presne. Znamena to totiz, ze neco neni neni synchronni.
Jasný. A "synchronní" znamená, že to není asynchronní, ne?

V synchronnim systemu zpracovani objednavek na takovy problem nenarazis.
Co to je "synchronní systém na zpracování objednávek"? Tam nejsou fronty? Nedá se to škálovat na víc počítačů? Když kliknu na webu, tak ten web zmrzne, dokud někdo ve skladu objednávku fyzicky nevyřídí a neklikne na "odesláno"?

Nebo co to je?
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Ondra Satai Nekola 09. 10. 2019, 11:52:02

V synchronnim systemu zpracovani objednavek na takovy problem nenarazis.
Co to je "synchronní systém na zpracování objednávek"? Tam nejsou fronty? Nedá se to škálovat na víc počítačů? Když kliknu na webu, tak ten web zmrzne, dokud někdo ve skladu objednávku fyzicky nevyřídí a neklikne na "odesláno"?

Přesně tak. Skutečně tam pak na takové problémy, jaké nese asynchronní programování, nenarazíš. Vlastně s tím nenarazíš ani na žádné praktické problémy, protože to prakticky nikde nenasadíš.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Pivotal 09. 10. 2019, 13:49:59
Reasoning
Co je zač tento korporátní termín?

Pro inspiraci: https://maxtaco.github.io/coffee-script/ - zde se používá await a defer
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Mirek Prýmek 09. 10. 2019, 13:56:11
Co je zač tento korporátní termín?
To nemá s korporacemi nic společného, to je vědecký termín. Znamená to mít schopnost správně (metodologicky korektně) o nějaké věci uvažovat a docházet tak k platným (teda i potenciálně prakticky využitelným) závěrům. Jak jsem řekl, neznám dobrý český ekvivalent, který by měl všechny tyhle odstíny. Rád si nechám poradit, ale není to nic z "uvažovat", "zvažovat", "přemýšlet", "vyvozovat", "odvozovat", "rozhodovat se". Má to (aspoň v mých očích) z toho všeho trochu a proto je to pro mě tak silný slovo.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 09. 10. 2019, 14:14:43
Co je zač tento korporátní termín?
To nemá s korporacemi nic společného, to je vědecký termín. Znamená to mít schopnost správně (metodologicky korektně) o nějaké věci uvažovat a docházet tak k platným (teda i potenciálně prakticky využitelným) závěrům. Jak jsem řekl, neznám dobrý český ekvivalent, který by měl všechny tyhle odstíny. Rád si nechám poradit, ale není to nic z "uvažovat", "zvažovat", "přemýšlet", "vyvozovat", "odvozovat", "rozhodovat se". Má to (aspoň v mých očích) z toho všeho trochu a proto je to pro mě tak silný slovo.
Vezmi si příklad ze srbštiny (automatsko rezonovanje)  ;)
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Mirek Prýmek 09. 10. 2019, 14:23:32
Vezmi si příklad ze srbštiny (automatsko rezonovanje)  ;)
To by nám kolidovalo s rezona(n)cí.

Typický počeštění by asi bylo "není schopnej toho rýzonování nad kódem", ale to se mi moc nelíbí :)

Stejnej původ asi bude mít "rozumování", ale tomu jsme dali negativní konotaci. Náš národ reasoningu i historicky moc nefandí :)
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 09. 10. 2019, 14:42:11
Vezmi si příklad ze srbštiny (automatsko rezonovanje)  ;)
To by nám kolidovalo s rezona(n)cí.

Typický počeštění by asi bylo "není schopnej toho rýzonování nad kódem", ale to se mi moc nelíbí :)

Stejnej původ asi bude mít "rozumování", ale tomu jsme dali negativní konotaci. Náš národ reasoningu i historicky moc nefandí :)
To byl vtip. Teď vážně, přinejmenším pro “automated reasoning” se ustálilo “automatické usuzování.” To je taky původní anglický význam, krom poněkud specifického “a Rastafari meeting held for the purposes of chanting, prayer and discussion.”  :)
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Mirek Prýmek 09. 10. 2019, 16:00:17
To byl vtip.
Však já vím.

Teď vážně, přinejmenším pro “automated reasoning” se ustálilo “automatické usuzování.” To je taky původní anglický význam, krom poněkud specifického “a Rastafari meeting held for the purposes of chanting, prayer and discussion.”  :)
"Usuzování" je dobrý. Je to dostatečně málo používané slovo na to, aby se tam nevloudily ty konotace lidového "mudrování", "rozumování" apod.

BTW, tohle je vtipný:
https://books.google.com/ngrams/graph?year_start=1800&year_end=2008&corpus=15&smoothing=7&case_insensitive=on&content=reasoning&direct_url=t4%3B%2Creasoning%3B%2Cc0%3B%2Cs0%3B%3Breasoning%3B%2Cc0%3B%3BReasoning%3B%2Cc0

I v anglickojazyčném kontextu se rýznuje čím dál míň, ale ok roku 1980  (cca vznik osobních počítačů!) je na vzestupu ;)

P.S. ten rastafariánský význam není zas tak okrajový, v reaggae se to objevuje často :)
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 09. 10. 2019, 16:38:23
To byl vtip.
Však já vím.

Teď vážně, přinejmenším pro “automated reasoning” se ustálilo “automatické usuzování.” To je taky původní anglický význam, krom poněkud specifického “a Rastafari meeting held for the purposes of chanting, prayer and discussion.”  :)
"Usuzování" je dobrý. Je to dostatečně málo používané slovo na to, aby se tam nevloudily ty konotace lidového "mudrování", "rozumování" apod.

BTW, tohle je vtipný:
https://books.google.com/ngrams/graph?year_start=1800&year_end=2008&corpus=15&smoothing=7&case_insensitive=on&content=reasoning&direct_url=t4%3B%2Creasoning%3B%2Cc0%3B%2Cs0%3B%3Breasoning%3B%2Cc0%3B%3BReasoning%3B%2Cc0

I v anglickojazyčném kontextu se rýznuje čím dál míň, ale ok roku 1980  (cca vznik osobních počítačů!) je na vzestupu ;)

P.S. ten rastafariánský význam není zas tak okrajový, v reaggae se to objevuje často :)
Když vidím “rýznuje,” napadá mě Ryzen.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PetrK 09. 10. 2019, 17:59:32
Ja si myslim, ze asyncrhonni znamena neco konkretniho a docela presne. Znamena to totiz, ze neco neni neni synchronni.
Jasný. A "synchronní" znamená, že to není asynchronní, ne?

V synchronnim systemu zpracovani objednavek na takovy problem nenarazis.
Co to je "synchronní systém na zpracování objednávek"? Tam nejsou fronty? Nedá se to škálovat na víc počítačů? Když kliknu na webu, tak ten web zmrzne, dokud někdo ve skladu objednávku fyzicky nevyřídí a neklikne na "odesláno"?

Nebo co to je?

"Slovo Asynchronie, asynchronní označuje stav, který není synchronizován"
https://cs.wikipedia.org/wiki/Asynchronie
 8)

Asynchronni system na zpracovani objednavek je system, ktery je uplne na 3.14cu 8)

Hosi nevyrabejte asynchronni systemy, nebo se z toho zblaznite.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Mirek Prýmek 09. 10. 2019, 18:22:07
Hosi nevyrabejte asynchronni systemy, nebo se z toho zblaznite.
No ještě jsi neodpověděl na otázku "Co to je "synchronní systém na zpracování objednávek"?", takže nevíme, co nemáme vyrábět.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Ondra Satai Nekola 09. 10. 2019, 18:23:43
Ja si myslim, ze asyncrhonni znamena neco konkretniho a docela presne. Znamena to totiz, ze neco neni neni synchronni.
Jasný. A "synchronní" znamená, že to není asynchronní, ne?

V synchronnim systemu zpracovani objednavek na takovy problem nenarazis.
Co to je "synchronní systém na zpracování objednávek"? Tam nejsou fronty? Nedá se to škálovat na víc počítačů? Když kliknu na webu, tak ten web zmrzne, dokud někdo ve skladu objednávku fyzicky nevyřídí a neklikne na "odesláno"?

Nebo co to je?

"Slovo Asynchronie, asynchronní označuje stav, který není synchronizován"
https://cs.wikipedia.org/wiki/Asynchronie
 8)

Asynchronni system na zpracovani objednavek je system, ktery je uplne na 3.14cu 8)

Hosi nevyrabejte asynchronni systemy, nebo se z toho zblaznite.

Neblábol.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PetrK 09. 10. 2019, 20:36:51
Hosi nevyrabejte asynchronni systemy, nebo se z toho zblaznite.
No ještě jsi neodpověděl na otázku "Co to je "synchronní systém na zpracování objednávek"?", takže nevíme, co nemáme vyrábět.

Synchronni system na zpracovani objednavek je system na zpracovani objednavek takovy, ktery nezpracovava objednavky asynchronne.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Mirek Prýmek 09. 10. 2019, 20:38:00
Synchronni system na zpracovani objednavek je system takovy, ktery je synchronizovat, a neni asynchronni.
"ktery je synchronizovat" je jakou řečí? :)
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Ondra Satai Nekola 09. 10. 2019, 20:51:45
Hosi nevyrabejte asynchronni systemy, nebo se z toho zblaznite.
No ještě jsi neodpověděl na otázku "Co to je "synchronní systém na zpracování objednávek"?", takže nevíme, co nemáme vyrábět.

Synchronni system na zpracovani objednavek je system na zpracovani objednavek takovy, ktery nezpracovava objednavky asynchronne.

A asynchronní definuješ

Ja si myslim, ze asyncrhonni znamena neco konkretniho a docela presne. Znamena to totiz, ze neco neni neni synchronni.

Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PetrK 09. 10. 2019, 21:10:43
Hosi nevyrabejte asynchronni systemy, nebo se z toho zblaznite.
No ještě jsi neodpověděl na otázku "Co to je "synchronní systém na zpracování objednávek"?", takže nevíme, co nemáme vyrábět.

Synchronni system na zpracovani objednavek je system na zpracovani objednavek takovy, ktery nezpracovava objednavky asynchronne.

A asynchronní definuješ

Ja si myslim, ze asyncrhonni znamena neco konkretniho a docela presne. Znamena to totiz, ze neco neni neni synchronni.

Genialni, ze?
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Mirek Prýmek 09. 10. 2019, 21:14:58
Genialni, ze?
Záleží na obecenstvu. Taky jsem to považoval za geniální, když jsem to používal na děcka. Ale asi tak od pěti let už to na ně nezabíralo, musel jsem přijít s něčím zajímavějším.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: listoper 09. 10. 2019, 21:32:08
Hosi nevyrabejte asynchronni systemy, nebo se z toho zblaznite.
No ještě jsi neodpověděl na otázku "Co to je "synchronní systém na zpracování objednávek"?", takže nevíme, co nemáme vyrábět.

Synchronni system na zpracovani objednavek je system na zpracovani objednavek takovy, ktery nezpracovava objednavky asynchronne.

A asynchronní definuješ

Ja si myslim, ze asyncrhonni znamena neco konkretniho a docela presne. Znamena to totiz, ze neco neni neni synchronni.

@PetrK: ted te dostal...
Mas dve moznosti:
1. Priznat chybu jako chlap.
2. Napsat nejakou kravinu jako treba "Genialni, ze?"

Edit: zatraceny asynchronni forum! Byl si rychlejsi....
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Ondra Satai Nekola 09. 10. 2019, 23:04:28
Interweby jsou kruté a asynchronní místo.  :'(
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PanVP 10. 10. 2019, 00:51:50
Měli byste se synchronizovat  :P
Místy se mi zdá, že odpověď přichází dřív než otázka.
To by se v synchronním světě nestalo.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PetrK 10. 10. 2019, 07:49:18
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 8)

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.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Ondra Satai Nekola 10. 10. 2019, 09:39:11
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...
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Jiří Havel 10. 10. 2019, 09:57:30
No a ja rikam, abyste neprogramovali asynchronne, protoze je to na 3.14cu, protoze to nema dobrou ergonomii 8)

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? ::)
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 10. 10. 2019, 10:37:41
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 8)

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ě.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: registrovany_ava 10. 10. 2019, 20:11:13
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
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 10. 10. 2019, 21:09:06
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í.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: luvar 10. 10. 2019, 22:46:35
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")
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PetrK 10. 10. 2019, 23:41:12
.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PetrK 10. 10. 2019, 23:54:04
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.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 11. 10. 2019, 00:24:40
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í.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PetrK 11. 10. 2019, 00:40:45
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.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Ladislav Jech 11. 10. 2019, 08:29:20
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...
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Martin Sivák 11. 10. 2019, 09:45:47
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ě.



Název: Re:Naučení se asynchronnímu programování
Přispěvatel: loblik 11. 10. 2019, 10:05:31
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" .
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 11. 10. 2019, 11:21:32
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.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PetrK 11. 10. 2019, 13:55:40
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ů.

Tomu neverim, proc by to tak na urovni jadra pouzivali ve smycce? Na urovni jadra se musi dat operovat primo s HW prerusenimi. Kdyz ti epoll obsluhuje 10000 socketu, tak kdyz ti na nejaky z nich prijde nova message, tak ta se tam na te nejvic low level urovni dopravila udalosti HW preruseni. Na urovni jadra uz musi byt k dispozici nastroje, ktere umi HW preruseni primo obsluhovat. Od systemove funkce jako je epoll ocekavam, ze prave toto umi, tzn. ze HW preruseni vyvola kaskadu udalosti, ktere provedou obsluhu jednoho z 10000 socketu z epoll Jinak bysis taky tu smycku mohl napsat sam pres neblokujici Socket::available(), coz je dost dementni reseni.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 11. 10. 2019, 14:08:30
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ů.
Tomu neverim
Epoll není hejkal, abys na něj věřil nebo ne. Prostě si to nastuduj a pak se sem přijď pokorně omluvit.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: loblik 11. 10. 2019, 14:43:08

Tomu neverim, proc by to tak na urovni jadra pouzivali ve smycce?

V jadre kvuli epollu zadna smycka neni. Smycka je v kodu uzivatelskeho programu kolem volani epollu. Epoll je potencionalne blokujici systemove volani. Pokud v dobe jeho zvolani neni v jadre zadna neosetrena udalost na kterou se aplikace zaregistrovala, je process zarazen do cekaci fronty. Ve chvili, kdy nastane alespon jedna z podminek, je proces z fronty vyjmut a volani epollu je dokonceno. Vysledkem volani je aplikace informovana o vzniklych udalostech, pripadne je osetri a pote se vraci smyckou zpatky na epoll.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PetrK 11. 10. 2019, 15:25:57
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ů.
Tomu neverim
Epoll není hejkal, abys na něj věřil nebo ne. Prostě si to nastuduj a pak se sem přijď pokorně omluvit.

Nasrat.

Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Ondra Satai Nekola 11. 10. 2019, 15:43:52
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ů.
Tomu neverim
Epoll není hejkal, abys na něj věřil nebo ne. Prostě si to nastuduj a pak se sem přijď pokorně omluvit.

Nasrat.

Co kdybys prostě mlčel o tématech, o kterých houby víš, když už to teda dostudovat nechceš?
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 11. 10. 2019, 16:07:05
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ů.
Tomu neverim
Epoll není hejkal, abys na něj věřil nebo ne. Prostě si to nastuduj a pak se sem přijď pokorně omluvit.
Nasrat.
Máme na fóru ovčáčka  ;D
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PetrK 11. 10. 2019, 16:32:01
Zaprve, ja vim dost na to, abych vedel, ze na backend do kodu zadne event loopy ani jine podobne srakcy nepatri. A Actor je taky solidni sracka  8)

A zadruhe, taky vim dost na to, abych vedel, jak je strasne na hovno kdyz ma jazyk coroutiny, protoze kokoti to pak pouzivaji uplne na vsechno misto aby to pouzivali s citem. Kazdou metodu pisou await async, ikdyz je to naprosto k nicemu.

Event loop je ted zrovna popularni v Jave ve Vertexu,  a nekteri by to chteli cpat na kazdou backendovou aplikaci, ikdyz je to nedebugovatelna sracka.

Na ten epoll se podivam o vikendu, tak jak pisete to urcite nefunguje, a toho sralbotku Sataie Nekolu si posleze podam  8)
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: gill 11. 10. 2019, 16:37:32
jak se čte z epoll bez event loopu?
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: kimec 11. 10. 2019, 16:42:56
Máme na fóru ovčáčka  ;D

Bonus body: pri teme o "asynchronnom programovani", nech uz to znamena cokolvek, som si dostudoval cesku politicku scenu.

forum.root.cz informace nejen ze světa Linuxu  :)
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Ondra Satai Nekola 11. 10. 2019, 17:05:47
Zaprve, ja vim dost na to, abych vedel, ze na backend do kodu zadne event loopy ani jine podobne srakcy nepatri. A Actor je taky solidni sracka  8)

A zadruhe, taky vim dost na to, abych vedel, jak je strasne na hovno kdyz ma jazyk coroutiny, protoze kokoti to pak pouzivaji uplne na vsechno misto aby to pouzivali s citem. Kazdou metodu pisou await async, ikdyz je to naprosto k nicemu.

Event loop je ted zrovna popularni v Jave ve Vertexu,  a nekteri by to chteli cpat na kazdou backendovou aplikaci, ikdyz je to nedebugovatelna sracka.

Na ten epoll se podivam o vikendu, tak jak pisete to urcite nefunguje, a toho sralbotku Sataie Nekolu si posleze podam  8)


Hodně názorů, málo znalostí. Zkus obrátit poměr.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 11. 10. 2019, 17:10:19
Máme na fóru ovčáčka  ;D
Bonus body: pri teme o "asynchronnom programovani", nech uz to znamena cokolvek, som si dostudoval cesku politicku scenu.
Upřímnou soustrast.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Mirek Prýmek 12. 10. 2019, 00:36:02
Bonus body: pri teme o "asynchronnom programovani", nech uz to znamena cokolvek, som si dostudoval cesku politicku scenu.

forum.root.cz informace nejen ze světa Linuxu  :)
Tak abysme to obloukem vratili zpatky k tomu IT, nemela by ti u te ceske politicke sceny uniknout tato dva roky stara kauza:

https://youtu.be/3GocCQcgYoc?t=704

Lahudka.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PanVP 12. 10. 2019, 00:38:50
Proveďme pokus:
Hyperbola neukončené funkce, letí množina Eulerova, synchronní funkcí sto psů zví!


Co lze o tom říct:
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PanVP 12. 10. 2019, 00:54:07

To byly časy, když tu byl občas Lenin, komix byl komix a šlo pod něj přidávat příspěvky, Blek měl poruchu osobnosti, Blek číslo dvě měl poruchu osobnosti, Blek číslo tři prvním dvou blekům záviděl poruchu osobnosti a tak předstíral.
 

Název: Re:Naučení se asynchronnímu programování
Přispěvatel: PetrK 12. 10. 2019, 10:25:15
Z epollu se samozrejme cte ve smycce, ale tady je celou dobu rec o Event Loop designu jak to ma Javacript, Node.js, Vertex, atp., a ne doprcic o tom, ze sis nekde v programu udelal while(true) a ctes neco ve worker threadu pres epoll.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: listoper 12. 10. 2019, 10:48:09
Z epollu se samozrejme cte ve smycce, ale tady je celou dobu rec o Event Loop designu jak to ma Javacript, Node.js, Vertex, atp., a ne doprcic o tom, ze sis nekde v programu udelal while(true) a ctes neco ve worker threadu pres epoll.

To "e" v epoll znamena "event". Ta samozrejma smycka na cteni je "loop". Nahoda?
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Idris 12. 10. 2019, 10:50:10
Z epollu se samozrejme cte ve smycce, ale tady je celou dobu rec o Event Loop designu jak to ma Javacript, Node.js, Vertex, atp., a ne doprcic o tom, ze sis nekde v programu udelal while(true) a ctes neco ve worker threadu pres epoll.
Jasně, ovčáčku.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Ondra Satai Nekola 12. 10. 2019, 11:58:05
Z epollu se samozrejme cte ve smycce, ale tady je celou dobu rec o Event Loop designu jak to ma Javacript, Node.js, Vertex, atp., a ne doprcic o tom, ze sis nekde v programu udelal while(true) a ctes neco ve worker threadu pres epoll.

Neztrapňuj se. S tím už jsi dávno hotový.
Název: Re:Naučení se asynchronnímu programování
Přispěvatel: Ovrscout 12. 10. 2019, 16:31:10
Omlouvám se za trochu delší text, ale je to tak trochu v rámci samostudia :)

Začnu trochu od konce,s epoll-em

Doufám že se shodnome na tom že e to vlastně jen takový rychlejší select/poll a v nejjednodušším případě se s ním pracuje v jednom vlákně. Dále také tak trochu předpokládám neblokující sockety.

Aby to dobře fungovalo pro všechna spojení, tak musí být obsluha rychlá a neblokující.

V každém trochu složitějším případě je práce v epoll smyčce řízená nějakým stavovým automatem. Např SSL_read může požadovat opakované volání (s návratem z volané funkce až k epoll s požadavkem na čekání až bude socket připraven na čtení nebo zápis) dokud není ssl spojení kompletně navázáno.
Podobně také může být třeba se opakovaně vracet až k epoll pokud třeba není vyčten celý příchozí povel atp.(záleží na protokolu).

Pokud se pracuje s jinými prostředky (např ty soubory, db, ..)  tak také nechcete brzdit epoll smyčku synchroním voláním. Např v tom vašem příkladu jste operaci ukládání na disk odsunul do samostatného vlákna, ale tím jste si přidal práci s frontou, předáváním dat mezi vlákny atp. Co když potřebujete předat zprávu zpět z toho externího vlákna? Vrátíte zrávu zpět do epoll vlákna, nebo si budete socket pollovat ve worker threadu?
Věci se mohou začít kompikovat pokud si nedáte pozor, nebo pokud je protokol složitější, případně uchovává složitější stav.

Souhrn:
- V hlavní smyčce nesmí být synchroní/dlouhotrvající operace
- stavové automaty, pokud si nedáte pozor mohou být peklo.
- prakticky nutnost předávání dat mezi vlákny - potenciální problém
- řízení uvolňování zdrojů, a předávání zpráv o chybách mezi vlákny a stavovými automaty může být problém.
+- Trochu to nutí programátora si aplikaci rozdělit
- škálování do více vláken může být problém (pro každou databázi/disk/... jedno vlákno)?

Pokud je úloha jednoduchá, může být řešení s epoll krásně přehledné, v opačném případě je třeba uvážlivě členit aplikaci.

Tak a teď ohledně async/await  (z pohledu c#)
Je to sice trochu složitější, ale dá se na to koukat jako na ten stavový automat co se používá u epollu.

Takové await se pak jakoby vrací z funkce do hlavního loopu (podobně jako by se vracelo k epollu) a "vrátí" se až když jsou data dostupná (např načtena dat přes socket) nebo pokud vznikla chyba.
Akorát je to implementováno trochu chytřeji, a neomezuje jen na sockety a async await je možný třeba i při přístupu k disku, databázi, nebo je možné snadno vrstvit třeba protokoly (TCP/IP + SSL + HTTP)
Trochu neplechu může vyvolat pokud se do práce vloží více vláken z ThreadPoolu, je třeba si pohlídat ConfigureAwait.
Ale s trochou zkušeností stačí dodržovat pár základních pravidel (podobně jako musíte dodržovat proavidla při tvorbě stavových automatů pro epoll).

S tím také trochu souvisí pravidlo, že pokud se používá async/await tak všechen (potenciálně blokující) kód by měl používat async/await, v extrémním případě spustit "blokující" kód v threadpoolu.
Navíc je nutné(pokud si nechcete zahrávat s deadlocky) používat await celou cestu vzhůru, a awaitovat výsledek namísto blokujícího task.Result a podobně.(což zjednodušeně znamený že i první funkce na stakcu měla být async, například main)
To je důvod proč možná narážíte na to že někdo "zbytečně" používá async/await.
Když se nad tím zamyslíte, tak je to vlastně logické, synchroní kód v hlavní "smyčce" blokuje provádění ostatních "Tasků" (ačkoliv zde je to trochu složitější, a špatný kód může "občas/často" fungovat nebo nefungovat kvůli připadnému provádění nebo neprovádění tasků v různých vláknech).

Souhrn:
- V hlavní smyčce nesmí být synchroní/dlouhotrvající operace
+ umí jednoduše asynchroně pracovat i s dalšími prostředky (soubory, připojení k databázi, uživatelské funkce používající async,..), ne jenom se sockety, to třeba umožňuje pěkně zapouzdřit komunikační protokol atd.
+ stavový automat za vás vygeneruje překladač (ačkoliv je dobré to tušit kvůli úspoře prostředků)
+- koncept async/await umožňuje v některých případech vyhnout se explicitnímu vytváření vláken úplně.
+- řízení uvolňování zdrojů, a předávání zpráv o chybách - celkem jednoduché jako v "synchroním" kódu, pokud
explicitně nepředáváte do workerthreadů zprávy jako v prvnímpřípadě.
+škálování do více vláken nemusí být problém
- Pokud nedodržíte základní pravidla (jako např. async/await all the way up, a pohlídat si ConfigureAwait) může kód fungovat díky shodě náhod a použitému synchronizačnímu kontextu(věc z C#).
- Pokud se věci zpracovávají na Threadpollu, je třeba si uvědomit že není nekonečný :)
- může být nutno explicině přiškrtit některé operace (což v předhozím případě mohl zajišťovat worker thread)
+ Stále je možno používat worker thready jako v předchozím případě, pokud to dává smysl.

Pro jednoduchou aplikaci, je to jednoduché, pro složitější trochu víc, ale víceméně to vypadá jako synchroní kód(s tím že je vidět kde stavový automat může navrátit řízení do "hlavní smyčky".
Pro oba případy je ale třeba dodržet základní pravidla.