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