Příspěvky

1006

Vývoj / Re:Uváznutí v Aktor systému

« kdy: 22. 10. 2019, 19:16:01 »

OK. I tak mě ale zajímá, jak bys řešil přístup k persistentnímu storage. A pak jestli bys nechal aktory komunikovat pomocí sběrnice, kde se mohou za běhu porůznu registrovat k odběru událostí jednotliví aktoři. Předpokládejme, že je cílem nějaký výpočetní cluster s probíhajícími výpočty, které na sobě porůznu závisí (nějaká simulace třeba).

Tezko rict, to je asi moc specificka otazka, ktera by zalezela na detailnich pozadavcich na ten system.

Obecne bych asi spis moc nepouzival slovo "sbernice", to do aktoroveho sveta imho moc nesedi. Pokud bych mel vypocetni cluster s nejakymi workery, kteri se hlasi o zadani vypoctu, tak bych mel asi nejaky "registr" aktor, kteremu by se worker ohlasil, ze chce praci a registr by workerum bud primo praci rozdeloval, nebo by jenom udrzoval jejich seznam a praci by rozdeloval zase jiny aktor. Zalezi hlavne na mnozstvi tech uloh - jestli by registr byl nebo nebyl uzky hrdlo...

Zavislosti se zase daji resit ruzne. Spawnovani novych actoru je typicky levne, takze casto se ruzne zavislosti daji resit treba tak, ze se spawne nekolik actoru a nekteri z nich proste cekaji na to, az se dokonci ulohy, na kterych jejich uloha zavisi. K tomuhle je ale dobry mit ten system "linku" - aby se dal cely ten "strom" actoru shodit naraz, pokud dojde k nejake chybe.

Persistentni storage je velky tema, silne implementacne zavisly. Jako rule of thumb bych se hlavne snazil dobre promyslet, jestli opravdu persistenci potrebuju. Mam zkusenost, ze dost casto se ukaze, ze vlastne vubec potreba neni.

Dam takovej pripad jedne veci, na ktere delam zrovna ted: jsou nejake streamy dat a nekdo nekdy v historii vymyslel, ze ty streamy budou oznacene nevyznamovymi IDcky (napr. "BFLM"). System funguje tak, ze prijdou data ze zarizeni, ktery ma ID treba "A", a v ramci toho zarizeni ma ten stream ID napr. "TEMP1" (je to teplota na prvnim cidlu). No a kdyz teda to dato prijde, tak se v databazi vyhleda mapovani (A, TEMP1) => BFLM a dal ten stream putuje pod timhle IDckem.

Zasadni otazka je, k cemu je vlastne to mapovani dobry. Co kdybych ten stream oznacil IDckem "A-TEMP1"? Prisel bych o neco? A pritom bych krasne odstranil perzistenci, databazi, pripadne i uplne stavovost...

To jenom takova drobna stupidni ilustrace...

1007

Hardware / Re:Stabilita ESP8266

« kdy: 22. 10. 2019, 17:26:39 »

Ale zabudovat podporu pro Čmoud přímo do tak malé krabičky, to je celkem super.

Mně to teda nepřijde ani trochu super. A za tu cenu už vůbec ne.

Připojení přes síť na domácí backend nebo na nějaký server kdekoli je poměrně triviální, když s tím má člověk zkušenosti.

Já osobně mám vynikající zkušenosti s combem MQTT + Node Red + Influx + Grafana. Pokud bych si chtěl postavit backend někde na AWSku, zvažoval bych třeba MQTT + AWS IoT + serverless web.

MQTT rozjedu na čemkoli za babku, mám to plně pod kontrolou a nemusím se bát, že se páni v Redmondu rozhodnou, že to zaříznou, protože je najednou cool něco jinýho...

1008

Hardware / Re:Stabilita ESP8266

« kdy: 22. 10. 2019, 17:21:33 »

pouzivate nekdo ESP8266 v nejake dulezitejsi aplikaci, u ktere je vyzadovana spolehlivost? A funguje to 100% ?

S ESP8266 mám hodně omezené zkušenosti. Imho v dnešní době není moc důvodů ho používat, 32ka je daleko lepší.

Co se stability 32ky týče, můžu potvrdit víceméně to, co tady už zaznělo: uptime v řádu cca měsíce. Pokud ti to přijde málo, ono to má dva důvody:

1. u hodně lidí prostě fakt jednou za x týdnů vypadne proud (stačí krátký výpadek, který jinak ani nezaznamenáš)
2. hodně lidí si s tím průběžně hraje, upgraduje, ...
3. většina lidí (imho) restarty moc neřeší, protože to na funkčnost nemá žádný vliv a aplikace by tak jako tak měla být napsaná tak, aby je přežila

Jinak, možná by pomohlo, kdybys trochu naťukl, co si pod tou "důležitější aplikací" představuješ (co je v sázce) a proč restart vadí. Oboje je totiž trochu podezřelé. To první proto, že ESP prostě není žádný "military grade" procesor a nemůžeš to od něj čekat. To druhý proto, že si neumím představit moc aplikací, kde by restart byl závažný problém (realtime řízení něčeho, co se nesmí zastavit? Na ESP?).

Mam par ESP8266 na nejake experimentovani (z eBaye), pravda, zapojene vselijak na stole, ale obcas se stava, ze se nektery z nich restartuje

Jako absolutně první věc bych řešil kvalitní napájení, pro jistotu ještě s kondíkem (wifi umí dělat nečekaně velké špičky). Jako druhou ten problém s watchdogem, to je známá věc.

1009

Vývoj / Re:Uváznutí v Aktor systému

« kdy: 22. 10. 2019, 15:49:52 »

A v případě aktorů by do té session přistupoval aktor nebo systém? Session může sloužit pro uložení ledasčeho, nejen autorizace. Ten storage na data bys řešil jak?

Já bych hlavně session v tomhle smyslu nepoužil. To byl BoneFlutuv napad.

1010

Vývoj / Re:Uváznutí v Aktor systému

« kdy: 22. 10. 2019, 09:41:13 »

Session znamená připojit stav k původně nestavovému protokolu. Zde vidím rozpor s tím, že jinde říkáš, že mají být aktoři nestavoví. Osobně bych se na session vykašlal, do aktorové koncepce IMHO moc nezapadá.

Myslím, že to BoneFlute řekl správně: pokud se všechna potřebná data drží v session, může být aktor nestavový.

Tenhle přístup se někdy používá v HTTP autorizaci. Jsou dvě cesty:
1. stavový aktor: klientům přiděluju IDčka a držím si tabulku "tohle ID má přístup do tehdy a tehdy"
2. nestavový aktor: do session uložím "přístup povolen do tehdy" a sám nemusím žádný stav držet (session ale musí být udělaná tak, aby s ní klient nemohl manipulovat - např. zašifrovaná serverem). Klient a server (aktor) si pak data session posílají tam a zpátky s každým requestem.

1011

Vývoj / Re:Uváznutí v Aktor systému

« kdy: 22. 10. 2019, 09:35:39 »

Ano, buď si musí ti aktoři předávat kompletní data (pak budou aktoři bezstavové funkce cca ve smyslu funkcionálního programování) anebo musí mít nějaké sdílené úložiště (např. databázi), tedy sdílený stav.

Drobná technická: v tomhle konkrétním případě žádné sdílené úložiště není potřeba, pokud aktor vykreslující grafy nebude nikdy požadovat historická data. Pokud bude jenom poslouchat přicházející data a z nich kreslit graf, tak potřebujeme držet jenom:
1. seznam aktorů, kteří data chtějí přijímat
2. buffer dat pro vykreslení grafu

První data si drží lokálně nějaký ten "distribuční" aktor, druhá data si drží lokálně grafovací aktor. Jsou potřeba jenom zprávy:
1. přihlašuji se k odběru
2. přibyl nový datapoint
3. odhlašuji se z odběru
a žádná sdílená data, žádná databáze.

1012

Vývoj / Re:Uváznutí v Aktor systému

« kdy: 22. 10. 2019, 08:53:44 »

U tohoto se prosím ještě zastavme. Já bych to řešil právě tou session. Přijde mi to takové intuitivnější. Aktor A + Zpráva + Session komunikace (kterou dodá obsluha). Tedy to, zda je ta zpráva od aktora B, nebo C(, nebo dokonce B jiná session) řeší runtime, a nikoliv vlastní Aktor. Aktor je jen a pouze vlastní logika. Takto si to představuju. V čem bych mohl narazit?

Proč bych měl chtít, pokud jsem tě pochopil dobře, aby aktor nepřeskakoval mezi klienty?

Já bych si přestavoval, že ten aktor je do značné míry bezestavový. Respektive ten stav je uložen mimo, ve službách a v session. Ale samozřejmě si rád vyslechnu proč je to blbej nápad :-)

Takže vlastně tvoje představa je spíš bližší HTTP než aktorovému systému ala CSP Jako proč ne? Klidně to tak udělat můžeš, ale pravděpodobně si tím na sebe uvalíš omezení, která ti pak neumožní dělat některé věci, které se v opravdovém aktorovém systému dělat dají, nebo budou zbytečně složité. Pravděpodobně se dostaneš k "něčemu podobnýmu RESTu" a hlavní otázka pak je, proč to vůbec dělat a nepoužít REST

Pokud bych měl říct konkrétněji, co mi přijde jako nevýhody takového řešení: pokud má runtime jakýmkoli způsobem manipulovat s komunikačními akty (např. je zhlukovat do těch sessions), tak:
1. musí té komunikaci rozumět (minimálně musí umět poznat začátek a konec)
2. buď teda budeš muset mít natvrdo jeden "metaprotokol" (např. zprávy "BEGIN" a "END" budou muset být součástí každé komunikace
3. nebo budeš muset nějak do runtimu nahrát popis protokolu
4. připravíš se o některé možnosti dynamického dispatche zpráv - u jednotlivých izolovaných zpráv můžeš třeba jednu konkrétní zprávu přehodit na jinýho aktora. Tady to nebudeš moct udělat, protože co by se pak dělo se session?

Už tohle je imho úplně zbytečný opruz, který tě bude stát jenom práci navíc, bude tě svazovat a nevidím žádný přínos, který by přinášel oproti klasice (neříkám, že neexistuje, jenom, že si ho teď neumím představit).

V klasickém aktorovém systému se můžeš ty, jako autor aktoru, rozhodnout, jestli v tu kterou chvíli komunikuje stylem "session" nebo stylem "ad hoc zpráva".  Prostě kód napíšeš tak nebo tak. Pokud budeš muset použít session, budeš mít úplně zbytečnou režii u komunikací, které session nijak nevyužijí (např. máš aktor, který čte stav tlačítka a když dojde ke změně stavu, pošle o tom zprávu jinému aktoru - to je bezestavová, jednozprávová komunikace, session tam k ničemu není).

Bez session:

A->B: switch=on
...
A->B: switch=off

S vynucenou session:

A->B: BEGIN
A->B: switch=on
A->B: END

+ režie toho, že někdo někde (úplně zbytečně) drží informace o té sešně.

Nevím, prostě se mi to intuitivně nezdá. Není to imho cesta správným směrem. Pokud chceš pochopit, na co jsou aktory dobré, drž se prostě CSP nebo toho, jak to má Erlang.

1013

Vývoj / Re:Uváznutí v Aktor systému

« kdy: 21. 10. 2019, 22:24:13 »

psát vlastní má smysl pro výukové potřeby

Což je myslím přesně to, o co BoneFlutovi jde - a je mu to ke cti

1014

Vývoj / Re:Uváznutí v Aktor systému

« kdy: 21. 10. 2019, 20:13:41 »

Minimálně pro tu prioritizaci, která se (AFAIK) jinak než selektivním vybíráním zpráv řešit nedá.

No vlastně dá se řešit nějakou předřazenou "proxy", ale to je zbytečně krkolomný. Selektivní vybírání je prostě lepší.

1015

Vývoj / Re:Uváznutí v Aktor systému

« kdy: 21. 10. 2019, 20:10:43 »

Já to mám vymyšlený tak, že runtime vyzvedává zprávy a ty potom prochází “volá” aktor s tou zprávou.

Můžeš to okomentovat v čem je to řešení výhodnější/zajímavější.

Při téhle implementaci pravděpodobně narazíš, protože ti tam chybí právě ta možnost, aby si sám aktor určil, kterou zprávu chce zpracovat. Jestli teda dobře rozumím tomu, jak to myslíš.

Jak to myslíš víc jak jednoho klienta?

Actor poskytuje nějakou službu a ostatní actory tu službu využívají - v té chvíli se jim dá říkat "klient", protože to de facto není v tu chvíli nic jinýho než starej dobrej klient-server.

Pokud ten protokol je stavový (tj. jeden akt/session/... se skládá z víc než jedné zprávy a mezi zprávama je potřeba si pamatovat stav), tak se to může (ale nemusí) implementovat tak, že se vyřídí jeden "akt" (několik zpráv) v celku a až pak se jde na druhej. Jenže pokud je víc klientů, tak se ty zprávy můžou prolínat - a ty si potřebuješ vybrat tu, kterou teď zrovna chceš zpracovat.

Příklad:
Máš protokol:
A -- hi --> B
A <-- welcome -- B
A -- bye --> B
[konec]

Aktora B chceš z nějakýho důvodu napsat tak, aby tohle celý zpracoval naráz (nepřeskakoval mezi klienty). Zprávy mu ale můžou přijít pomíchaný:
1. A -- hi --> B
2. A <-- welcome -- B
3. C -- hi --> B
4. A -- bye --> B

- potřebuješ nutně možnost vybrat si selektivně zprávu 4. a teprve potom 3.

Možná se ti zdá, že tohle dělat nemusíš a dá se to obejít (třeba spawnutím spešl aktoru pro každou session). Stoprocentně ale narazíš na situaci, kdy to budeš potřebovat. Minimálně pro tu prioritizaci, která se (AFAIK) jinak než selektivním vybíráním zpráv řešit nedá.

1016

Vývoj / Re:Uváznutí v Aktor systému

« kdy: 21. 10. 2019, 09:41:14 »

5. Actory mají nezávislá vlákna provádění (je asi víc způsobů, jak tohle definovat, ale já bych řekl, že prostě zacyklení jednoho agenta nesmí způsobit vyhladovění jiných agentů).

K tomuhle bych ještě doplnil: nevím, jestli je to nutný, ale každopádně je imho nejlepší mít na agenta právě jedno vlákno. Velice to zjednoduší vývoj a usuzování nad kódem.

1017

Vývoj / Re:Uváznutí v Aktor systému

« kdy: 21. 10. 2019, 09:38:08 »

No já si to představoval tak, že ti dva aktoři se zaciklí tak, že mi to shodí/extrémně vytíží ten runtime ve kterém to běží.
Ale to by se dalo řešit nějakým timeoutem, prioritizací, nebo tak něco.

Já bych řekl, že taková situace se prostě neřeší, protože není účelné ji řešit. V praxi máš prostě systém něčím monitorovaný (Icinga apod.) a pokud se tam děje cokoli, co ti přijde divné (pod to patří i vyhulení CPU), tak se prostě koukneš, co se tam děje, to je celý, nic víc bych nehledal/neočekával.

Je to tak. Píšu si vlastní systém/runtime.

Napiš cokoliv ti přijde že by se mohlo hodit. Budu rád.

Ok, tak já ti napíšu ty zásadní body, jak komunikace funguje v Erlangu. V průběhu používání jsem zjistil, že každá featura má svoje opodstatnění, i když to tak třeba na první pohled nevypadá. Nechci říct, že tohle je jediná možnost implementace, ale tvrdím, že je to kombinace featur, která je dobře vymyšlená a v praxi velmi dobře otestovaná.

Must have:

1. Komunikace je striktně asynchronní (A pošle zprávu B, součástí zaslání není čekání na odpověď ani potvrzení). To je proto, že synchronní komunikace se dá pomocí asynchronní implementovat, ale naopak ne.

2. Každý proces (aktor) má mailbox. Zprávy se doručují striktně do mailboxu. Vždy přes něj projdou, nikdy se nekomunikuje "napřímo".

3. Zprávy je možné z mailboxu vybírat selektivně (ideální je na to pattern matching). To je potřeba nejenom kvůli prioritizaci, ale i kvůli tomu, abys mohl mít stavový protokol a zároveň víc než jednoho klienta.

4. V jazyce existuje nějaký mechanismus, kterým se dá čekat na konkrétní zprávu (opět pattern matching...). Ideálně samozřejmě ne stylem busy waiting, že jo...

5. Actory mají nezávislá vlákna provádění (je asi víc způsobů, jak tohle definovat, ale já bych řekl, že prostě zacyklení jednoho agenta nesmí způsobit vyhladovění jiných agentů).

Nice to have:

1. Neexistuje sdílená paměť mezi actory. (Pokud bys chtěl dodržet čistý actor model, tak by tohle patřilo mezi must have, já to tam nedávám, protože i se sdílenou pamětí by to šlo implementovat - akorát si tím způsobíš víc problémů než užitku...)

Hodí se, když "něco jako" sdílená paměť existuje, ale má to velmi striktní pravidla. Např. to nefunguje jako normální paměť, ale spíš jako databáze, u které se dá líp kontrolovat, kdo, kdy a jak tam přistupuje. V Erlangu se tohle jmenuje ETS. Snadno si vygooglíš spoustu článků o tom, jak to funguje. Nepoužívá se to často, ale existují případy, které by se bez toho implementovaly obtížně. Pro tvoje účely bych se na to zatím vyprdl a řešil to případně až narazíš na případ, kterej bez toho nepůjde dobře řešit.

2. Zprávy jsou čistě datové (tj. nesmí obsahovat ukazatele apod.) - tady opět platí to, co je v závorce u předchozího bodu.

3. Velice se hodí (ale není to striktně nutné) mít nějaký způsob supervize actorů. V Erlangu je na to několik primitiv a pracuje se s nima báječně. Klíčová slova: link, monitor, supervisor, supervisor tree.

4. V Erlangu existuje konvence "fail fast" nebo "let it crash", která říká, že nejlepší je velkou část chybových stavů řešit prostě pádem komponenty a jejím restartem supervisorem než nějakým složitým rozlišováním chyb a selektivním zotavením. Vypadá to divně, ale v praxi je to IMHO fakt hodně dobrý přístup. Řešíš totiž jenom jeden problém - supervizi. A jakmile ho vyřešíš dobře, máš víceméně kompletně vyřešenou obsluhu chyb

1018

Vývoj / Re:Uváznutí v Aktor systému

« kdy: 21. 10. 2019, 06:29:40 »

Když napíšu takovýto kód v Cčku, co se stane. Spustím to, a process bude vesele vyžírat prostředky, dokavad ho něco nezabije. Domnívám se, že nemůže nastat situace, že jsem si tím zasekl počítač, a můžu ho vyhodit.

Úplně prakticky ne. Ten proces vyžere jedno jádro na 100% a poběží pořád, dokud ho nezabiješ ručně. Systém nemá důvod ho zabíjet, protože nezjišťuje, jestli proces dělá něco užitečného, nebo ne. Z pohledu systému ten proces není ničím divný, nenárokuje si pořád další a další prostředky, prostě jenom běží, na čemž není nic špatného (porovnej s odpověďmi kolegů výš, které říkají "na takové komunikaci není nic špatného").

A přesně to je pointa téhle analogie: přistupuješ k situaci "symptomaticky". Dělá ten proces, co dělat má? Ok, není co řešit. Nedělá? Zabiješ ho a budeš debugovat. Žere víc CPU než bys očekával? Zabiješ ho a budeš debugovat. Žere víc a víc paměti? Asi je tam memory leak. Zabiješ ho a budeš debugovat.

Žádná předběžná analýza kódu se v tomhle případě prostě nedělá. Program se spustí a až při běhu se zjišťuje, jak se chová. Ne, že by to bylo kdovíjak elegantní, ale je to pragmaticky nejlepší řešení.

V případě Aktorového systému jsem na tom podobně. Vzhledem k tomu, že to může být třeba přes vícero počítačů, tak když tam někdo zanese nějakou chybu, tak já nechci aby mi to všechno lehlo popelem. Zajímalo by mě to něco. Zajímalo by mě, jestli tomu můžu nějak zabránit. Ne absolutně, ne úplně. Ale alespoň trochu.

Tady mě zaujalo to slovo "všechno". Actor systém musí být udělaný tak, že jednotlivé actory jsou opravdu nezávislé. Takže nejhorší, co se ti může stát, je, že jeden actor (A) přestane fungovat. A případně ta jeho nefunkčnost způsobí nefunkčnost aktorů, které na něm závisí (B,C). V žádném případě by se ale nemělo stát, že přestane fungovat "všechno", zejména ne actor D, který s A ani B a C vůbec nekomunikuje.

Jak to zjistíš? No úplně stejně jako v té analogii: symptomaticky. Systém prostě přestane dělat to, co dělat má, a ty se budeš pídit po příčině. Žádnou větší vědu v tom nehledej, KISS!

Takovej nejjednodušší, ale velmi účinej způsob, jak takové situaci "předcházet", je mít u každého actora funkci/endpoint/... ping, a pravidelně pomocí nějakýho monitoringu kontrolovat jeho živost. Jinej možnej způsob je kontrolovat jenom vnější funkce systému (to, co tě jediný ve finále zajímá, je, jestli funguje systém jako celek - jestli poskytuje okolnímu světu to, co poskytovat má).

V Erlang světě se ale ten ping na každého actora (AFAIK) nepoužívá - není to prostě potřeba, protože to, čeho se bojíš, se moc často neděje a když se to stane, tak se to velmi rychle objeví. Ty důvody, proč se to neděje, jsou (jak jsem psal výš) spíš designové, než jakékoli jiné.

Jen se snažím vysvětlit svůj dotaz, když se evidentně tak blbě vyjadřuju.)

Neber si to vůbec osobně. Jenom jsem chtěl říct, že přesný definování problému pomocí adekvátních pojmů, je obvykle polovina řešení problému, však to znáš. Plavání v nejasných definicích a mlhavých problémech většinou nikam nevede...

---
P.S. Jak jsem tohle psal, tak mě napadlo, jestli náhodou se na tohle všechno neptáš proto, že zkoušíš napsat ten vlastní actorový systém (tj. tu vlastní infrastrukturu si píšeš sám). Pokud je to ten případ (nepoužíváš Erlang, Akka, ...), tak to určitě řekni, protože to by dost měnilo situaci. V tom vlastním systému je totiž potřeba dodržet pár věcí, které nejsou moc intuitivně zjevné a pokud je nedodržíš, nebude ti to fungovat. Těch věcí je jenom pár a můžu ti je vyjmenovat, pokud to potřebuješ.

1019

Vývoj / Re:Uváznutí v Aktor systému

« kdy: 20. 10. 2019, 20:13:35 »

každá komunikace má timeout. Problem solved

Tady bych asi ještě jednou zdůraznil: každá synchronní komunikace. Tj. odešlu požadavek a čekám na odpověď, mezi tím žádné další požadavky nepřijímám ani neodesílám.

1020

Vývoj / Re:Uváznutí v Aktor systému

« kdy: 20. 10. 2019, 20:03:52 »

Přemýšlel jsem, co ti na to napsat, a nakonec budu asi spíš stručnej. Jestli se v některým bodě trefím, můžem o tom třeba diskutovat šířejc.

1. Velice pravděpodobně řešíš pseudoproblém. Zapomeň úplně na aktory a převeď si to na tenhle dotaz:

Učím se céčko a není mi jasný, jak zamezit tomuhle:

Kód: [Vybrat]

int f() {
  return g();
}
int g() {
  return f();
}

Nechce se mi spoléhat na to, že ty funkce budou napsány správně.

Odpověď je stejná jako tvůj dotaz k Erlangu/Akka/... - nezaručuje se to obvykle nijak (v přísném, matematickém smyslu). Nepřímo je to totiž zaručeno tím, že kód má nějakou logickou strukturu a smyčka ve volání dost pravděpodobně znamená nějaký designový problém.

2. Vyjadřuješ se (z mýho pohledu) dost nejasně. Buď svoje myšlenky jenom (mně) nesrozumitelně vyjadřuješ, nebo je problém hlubší a o věci i přemýšlíš ze špatného úhlu pohledu.

V praxi to prostě bývá tak, že aktor implementuje nějaký kontrakt/protokol/API/... (je jedno, jak tomu chceme říkat) a ten obvykle bývá velice jednoduchý, mj. právě proto, aby bylo zřejmý, jestli aktor dělá to, co dělat má, dlo se to testovat, a zároveň to, co dělat má, nebyl nějaký nesmysl.

Úplně polopaticky: typicky actor implementuje třeba pattern request-response. Pošleš mu číslo a on ti vrátí jeho dvojnásobek. Není tam co řešit. Buď vrátí správný číslo a je to ok, nebo nevrátí a něco je blbě. Víc nad tím není co dumat.

Poučení: ujasni si, co má actor dělat, jaké má stavy (popř. jestli vůbec má stavy) a jakým komunikuje protokolem. Pokud chceš garantovat nějaké vlastnosti protokolu, uvažuj nad ním jako nad protokolem a úplně (pro tu chvíli) zapomeň na actory.

Poučení 2: Typicky čím míň má protokol omezení, tím míň jeho vlastností jsi schopen garantovat. A naopak. Snažit se dumat nad obecným protokolem, kde může docházet k čemukoli, moc nedává smysl. Jenom se v tom utopíš a nikam se nedostaneš.

3. Pokud jdeš králičí norou ještě o kousek hloub, skutečně v Erlang světě nastává problém podobnej tomu, co popisuješ. Je způsobenej tím, že pokud je actor stavový (což typicky je), pak má nutně jenom jedno vlákno (v úplně obecném smyslu "vlákno výpočtu", ne nutně OS vlákno apod.). Takže pokud máš komunikaci stylem A->B->C a ta komunikace je synchronní, tak dokud C neodpoví, A nemůže vyřizovat žádné další požadavky (např. X->A). Z toho taky plyne, že pokud se ti tam objeví komunikace A->B->A, dojde k deadlocku.

Je to principiálně dost nepříjemná věc, ale řešení je velmi stupidní, ehm. teda "pragmatický": každá komunikace má timeout. Problem solved

----

Vím, že neodpovídám přesně na dotaz, ale snad jsem se trochu trefil do něčeho, co tě může posunout. Jak jsem říkal, jestli chceš, můžem o tom trochu podebatovat, moc rád pomůžu, pokud budu schopen. Erlang je moje láska, takže mi dělá radost, že se tímhle světem někdo zabývá