Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
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.
Upřímnou soustrast.Máme na fóru ovčáčkaBonus body: pri teme o "asynchronnom programovani", nech uz to znamena cokolvek, som si dostudoval cesku politicku scenu.
Máme na fóru ovčáčkaNasrat.Epoll není hejkal, abys na něj věřil nebo ne. Prostě si to nastuduj a pak se sem přijď pokorně omluvit.Tomu neverimTo 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ů.
Epoll není hejkal, abys na něj věřil nebo ne. Prostě si to nastuduj a pak se sem přijď pokorně omluvit.Tomu neverimTo 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ů.
Po procteni tohoto vlakna jsem nabyl dojmu, ze je v nasich radach velka spousta jedincu, kteri jako kontraktori zpusobili svemu chlebodarci skodu a museli ji ze sveho uhradit. Tak bych se chtel zdejsich diskuteru zeptat, zda alespon vedi o nekom, komu se to realne stalo, co tomu predchazelo a jak to dopadlo. Chapu, ze riziko, ze svemu chlebodarci zpusobite skodu, existuje. Zajima me tedy, jak je velke.Levnější je založit prostě společnost s ručením omezeným, kde se neručí celým majetkem.
Vsichni tu jako velkou nevyhodu prace na ICO zminuji prave to ruceni vlastnim majetkem, tak se jako spravny cechacek logicky zajimam o mozne zpusoby, jak vlastni majetek minimalizovat. Jeden navod jak na to nam vlastne dal nas vladce-koblihar. Zalozim sverensky fond, do ktereho vlozim svuj vlastni majetek a stanovim se jeho spravcem a zaroven budu spolu s manzelkou a detmi jeho beneficientem. Z pravniho hlediska tedy nejsem vlastnikem a pripadny veritel se muze jit klouzat. Ma nekdo zkusenosti s timto konceptem, nebo jsem jen prilis paranoidni?
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.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" .
Řešení přes epoll implikuje smyčku událostí.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.
V případě kooperativního scheduleru je zásobník vždy jakoby byl kód synchronní.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
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.Smyčka událostí je synchronní, až použití NIO nebo něčeho podobného dodá kódu na asynchronicitě.
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.
Když vidím “rýznuje,” napadá mě Ryzen.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
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.”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í
Vezmi si příklad ze srbštiny (automatsko rezonovanje)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.
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á nicTos ale blbě pochopil, tím Idris myslel monomorfismusTo 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.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.
