Příspěvky

1171

Vývoj / Re:CSP v embedded světě

« kdy: 16. 03. 2021, 14:10:18 »

Je nutné (pro obecné praktické CSP). Představ se, že chci mít kanál pro rušení operací čtení z nějakého datového kanálu. Tento kanál (říkejme mu třeba “dropdead”) může být použit v mnoha selectech zároveň. Když chci všechny tyto selecty přerušit naráz, nemůžu jen poslat hodnotu, protože tu přečte jen jeden (náhodně vybraný), to je ostatně princip použití kanálů pro load balancing. Proto se to řeší tak, že se tento kanál zavře, pročež se všechny příslušné selecty odblokují a vyskočí se z nich. Všechny implementace CSP, co znám, to takto mají. Nejspíš to ani jinak (bez nárůstu složitosti) nejde. A je to elegantní.

Jasný, prostě context.Context. Nutný to není, dá se to udělat jinak. A dokonce i elegantněji V Erlangu jsou to linky (viz spawn_link). To je daleko robustnější řešení, protože nezávisí na kooperaci konsumenta. Mně tohle zavírání kanálů přijde spíš jako jejich zneužití. Z jistého pohledu to elegantní je, z jiného nikoli

Shodou okolností jsem přesně na tohle právě teď pěkně nasranej, protože píšu server, který musí obsluhovat net.Conn a zároveň kanály. Právě proto (!), že context.Context funguje přes kanály, není s net.Conn.Read kompatibilní a musí se kolem toho dělat opičky. Nevede to k elegantnímu kódu, ale přesně naopak...

Context není dělaný pro net.Conn. Jistě by to šlo přes síťové kanály, které ovšem zatím nikdo nenapsal (vlastně napsal a pak zahodil, to vyjde nastejno).

1172

Vývoj / Re:CSP v embedded světě

« kdy: 16. 03. 2021, 13:49:10 »

Nejsem si uplne stoprocentne jistej, jestli je zavirani kanalu nutny. Muzes zkusit trochu detailneji popsat, proc si pripadne myslis, ze jo?

Idealni by byl nejakej protipriklad - priklad konkretni situace, ktera bez zavirani kanalu nepujde vyresit.

Je nutné (pro obecné praktické CSP). Představ se, že chci mít kanál pro rušení operací čtení z nějakého datového kanálu. Tento kanál (říkejme mu třeba “dropdead”) může být použit v mnoha selectech zároveň. Když chci všechny tyto selecty přerušit naráz, nemůžu jen poslat hodnotu, protože tu přečte jen jeden (náhodně vybraný), to je ostatně princip použití kanálů pro load balancing. Proto se to řeší tak, že se tento kanál zavře, pročež se všechny příslušné selecty odblokují a vyskočí se z nich. Všechny implementace CSP, co znám, to takto mají. Nejspíš to ani jinak (bez nárůstu složitosti) nejde. A je to elegantní.

1173

Vývoj / Re:CSP v embedded světě

« kdy: 16. 03. 2021, 13:36:42 »

Ten “lokální buffer” mě napadl včera, když jsem psal předchozí příspěvek, ale IMHO žádný buffer není vůbec potřeba.

Prisne vzato neni, protoze kanal s konecnou kapacitou ma stejny potencialni dusledky jako kanal s kapacitou 1. Nekdy se proste muze zablokovat. A to je asi tak vsechno Jiny by to bylo s kanalem s neohranicenou kapacitou, ale nad tim predpokladam nepremyslis.

Ne, to dost dobře nejde a ani mě teď nenapadá, k čemu by to bylo.

1174

Vývoj / Re:CSP v embedded světě

« kdy: 16. 03. 2021, 10:15:00 »

Nad tím bufferem jsem taky přemýšlel a klidně bych to vypustil, tj. mít jen blokující kanály na zápis i čtení. Co je důležité (aby to k něčemu bylo) je zavírání kanálů, ani ne tak kvůli čtení ve smyčce, jako spíš signalizaci v kontextu (korutina, která čeká na čtení, se probudí, když se příslušný kanál zavře).

Já si (po zkušenosti s Elixirem) pořád myslím, že mailbox se selektivním výběrem je daleko mocnější nástroj, ale pro jednoduchou implementaci by nebufferované kanály imho měly stačit.

Bufferovaný kanál by se z nebufferovaného dal udělat, pokud by byla k dispozici operace testu, jestli je kanál prázdný. Pak můžu v případě potřeby ukládat do lokálního bufferu. Nenapadá mě teď případ, ve kterém by to nebylo funkčně ekvivalentní k "nativnímu" bufferu.

Kromě toho, nevybavuju si, že bych se někdy setkal se situací, kde by buffer na kanálu byl nutně potřeba pro korektnost algoritmu a nedalo by se to napsat jinak.

Mocnější to bude, ale já na to právě koukám stylem “jak mít za málo peněz hodně muziky,” tj. použít nejméně mocné (nejjednodušší) prostředky k dosazení cíle.

Ten “lokální buffer” mě napadl včera, když jsem psal předchozí příspěvek, ale IMHO žádný buffer není vůbec potřeba. Spíš se zaměřuju na zdánlivě nepodstatné, ale veledůležité detaily, třeba to zavírání kanálů, aby šel udělat fan in/out s kontextem apod.

1175

Vývoj / Re:CSP v embedded světě

« kdy: 16. 03. 2021, 00:02:14 »

Tak mě napadá, jak tam hodláš řešit select?

Takhle nízko ještě nejsem, zatím mám jenom mlhavou, high-level představu.

Nad tímhle jsou ještě jiná zajímavá rozhodnutí - jestli pojmenovávat kanály nebo procesy, jestli si vystačit s nebufferovanými kanály nebo přidat nějakou kapacitu, jestli kanál pojmout jako frontu nebo mailbox, jestli umožnit selektivní výběr zpráv...

Jestli má jít o srandu na jedno dvě odpoledne, tak to vidím na pojmenované kanály bez kapacity a tímpádem bez selektivního výběru. V takovým jednoduchým případě by select neměl být nic, nad čím by bylo potřeba dumat (?). Prostě z množiny kanálu náhodně vybereš jeden připravený ke čtení. Pokud by tam byl ten run to complete scheduler, tak by select vůbec nemusel být potřeba se mi intuitivně zdá.

Nad tím bufferem jsem taky přemýšlel a klidně bych to vypustil, tj. mít jen blokující kanály na zápis i čtení. Co je důležité (aby to k něčemu bylo) je zavírání kanálů, ani ne tak kvůli čtení ve smyčce, jako spíš signalizaci v kontextu (korutina, která čeká na čtení, se probudí, když se příslušný kanál zavře).

1176

Vývoj / Re:CSP v embedded světě

« kdy: 15. 03. 2021, 21:56:17 »

To CSP je to zajímavé, scheduler je tam prostě z nutnosti

Presne! Scheduler je tam jenom technikalie, kterou je proste potreba nejak vyresit, aby to "svítilo a hřálo", jak říká klasik

Tak mě napadá, jak tam hodláš řešit select?

1177

Vývoj / Re:CSP v embedded světě

« kdy: 15. 03. 2021, 15:25:11 »

Nádhera, nad CSP se pak dají udělat semafory, generátory, promises apod. Třešničkou by byly kanály mezi dvěma MCU (něco jako netchan v Go).

Bingo! To jsem právě naťukl v tom původním vláknu s tím PRU na Beaglebone. To jsou dva oddělený procesory. A jakmile by bylo CSP rozchozený, je to už jenom kousek k dalším srandám.

Takže co třeba dvě Blue Pills za padesátikorunu jedno, propojené přes CAN bus a tasky migrují z jednoho na druhý podle zatížení CPU? Proč ne A když jsme u toho CAN busu, co třeba deset propojených Blue Pills a jeden blink task migruje z jednoho na druhý, takže každou chvilku blikne s LEDkou jinde? To jako motivace nestačí? Tak to už fakt nevím co teda

Tento příklad mne motivoval se zapojit do diskuze 

Představujete si to tak, že ten task nasadím jen na jednom node a on se sám distribuuje (tedy musí se přenést spustitelná podoba) anebo tak, že jsou nasazené na všech nodech (už tam je spustitelná podoba) a distribuuje se jen to vykonání? A zrovna u toho blikání jak synchronizovat čas (asi bychom chtěli, aby to blikalo alespoň přibližně ve správném itervalu)?

Přiznám se, že CSP neznám, ale podle popisu na wikipedii je to přesně to, co by se mi líbilo. IMHO divné že to už neexistuje (nebo existuje?).

To druhé, ale přenášet přes kanály spustitelný kód by bylo taky zajímavé (zvlášť na MCU)

CSP existuje v mnoha podobách, jen na MCU moc ne. Třeba Pico má kanály pro komunikaci mezi vlákny (je dvoujádrové), tady se ale bavíme spíše o "userspacu" (kooperativní scheduler s podporou kanálů). Ve skutečnosti se vlastně bavíme o Go v pár kilobajtech paměti...

1178

Server / Re:Databáze - 300 GB tabulka

« kdy: 15. 03. 2021, 12:17:09 »

na takovehle akce pouzivam vetsinou SQLite.

Kdysi jsem se o něco podobného s SQLite pokoušel a dopadlo to neslavně. Asi jsem dělal něco hodně špatně.

To výše zmíněné rozsekání na "partitions" zní jako dobrý nápad.

1179

Vývoj / Re:CSP v embedded světě

« kdy: 15. 03. 2021, 11:05:54 »

Na cem jedete, ja chci taky takovej caj

Tyhle látky začne mozek produkovat přirozeně sám, stačí par let programovat v Elixiru

Nejen Elixiru. Spíš stačí v praxi narazit na zajímavé problémy a po letech pokusů a omylů dokonvergovat k best practices (např. CSP).

1180

Vývoj / Re:CSP v embedded světě

« kdy: 15. 03. 2021, 01:46:58 »

To CSP je to zajímavé, scheduler je tam prostě z nutnosti

Presne! Scheduler je tam jenom technikalie, kterou je proste potreba nejak vyresit, aby to "svítilo a hřálo", jak říká klasik

Nádhera, nad CSP se pak dají udělat semafory, generátory, promises apod. Třešničkou by byly kanály mezi dvěma MCU (něco jako netchan v Go).

1181

Vývoj / Re:CSP v embedded světě

« kdy: 15. 03. 2021, 01:35:01 »

moje predstava neni jenom o scheduleru, ale o tom celkovem systemu CSP, ktery prave jenom dohromady dava smysl.

To CSP je to zajímavé, scheduler je tam prostě z nutnosti

1182

Vývoj / Re:CSP v embedded světě

« kdy: 15. 03. 2021, 01:14:50 »

Představuju si to jako punkovou srandu, implementovanou cestou nejmenšího odporu, v tom stylu, jak píše Křišťan. Když to bude blikat deseti LEDkama s tím, že třeba jenom dvě bliknutí zařídí jeden task a pak nějaký "supervisor" spustí automaticky další, bude to v mých očích mission accomplished

Tak se pak pochlub

1183

Vývoj / Re:CSP v embedded světě

« kdy: 15. 03. 2021, 00:56:38 »

Samozřejmě se nebudu babrat s překladačem, na to fakt čas nemám, jde mi jenom o naimplementování těch primitv v C.

V C? To asi nebude problém. Já kdysi napsal korutiny pro C na AMD64 a pak se mi to nějak povedlo přepsat i pro ARM (je to kupa let zpátky, tak asi ARM32, ale už si to nepamatuju, jen že to běhalo na iPhonu). Kanály tam nějak byly taky, ale ty nejsou problém. Zkusím to najít, co si tak pamutuju, největší opruz byl scheduler. Sranda taky bude rozběhat to na více jádrech (třeba Zobák má dvě).

1184

Vývoj / Re:CSP v embedded světě

« kdy: 15. 03. 2021, 00:44:36 »

Jo, občas se kopíruje paměť (při nafukování zásobníku), proto se ti občas pod rukama změní ukazatel na instanci objektu (to může být zábavné, když v Go předáš ukazatel přes cgo někam ven a runtime ho při nafukování aktualizuje)

To mi neva, můj quick&dirty pokus, jesti se k němu někdy dostanu, rozhodně ukazatele podporovat nebude

A co to bude za jazyk?

1185

Vývoj / Re:CSP v embedded světě

« kdy: 15. 03. 2021, 00:43:22 »

Ten tvůj "divoký" nápad

Nepopírám, že divoký. Nikdy jsem se tímhle nezabýval, překladače nikdy nebyly moje hobby

V jádru není divoký, jen prostě brainstormingově napsaný Glad to be of help