Uváznutí v Aktor systému

Re:Uváznutí v Aktor systému
« Odpověď #30 kdy: 19. 10. 2019, 20:11:18 »
K čemu slouží zprávy OK?

Pokud Vám aktor B poskytl odpověď, proč mu znova posíláte další potvrzovací zprávy?
Pokud je to proto, aby si i aktor B byl jist, že odpověď došla, tak to je cesta do pekel - donekonečna se budou navzájem ujišťovat o tom, že si navzájem odpověděli.

V této konkrétní komunikaci je aktor A ten, kdo má zájem na výsledku a proto postačí, pokud od B dorazí odpověď.
B nemusí vědět, zda odpověď došla. Pokud by nedošla, tak ho A sám znovu upozorní.
Pokud A tedy nedostane v nějakém očekávaném časovém limitu odpověď, může se pokusit poslat požadavek znovu.

V reálném případě, kdyby požadavek měnil výrazným způsobem stav aktora B, a tudíž znova vykonaný požadavek by nežádoucím způsobem změnil opět stav B, řeší se to např. tak, že A očísluje své zprávy.
Pokud A tedy pošle znovu zprávu se stejným číslem, B už ví, že na ten požadavek odpověděl a pošle např. tutéž nacachovanou odpověď, aniž by měnil svůj stav.

Předpokládejme dva aktory A a B.
A -> B: kolik je hodin
B -> A: 19:41
A -> B: supr, díky
B -> A: není zač


Re:Uváznutí v Aktor systému
« Odpověď #31 kdy: 19. 10. 2019, 22:41:02 »
Sledovat opakující se vzory by mohlo fungovat. Ale je třeba - jak už to někdo uváděl - rozlišit chybu od záměru. Napadají mě dvě metody, ale určitě se najdou další:

1. Pokud je opakování až po nějaké době, pravděpodobně to nebude chyba ale záměr.
2. Pokud má být záměrem opakující se vzory, tak může pomoct, aby to ten objekt musel nějak explicitně vyjádřit, například speciálním druhem zprávy, nějaký příznakem, hashem, něčím.

Rozhodně to ale není neprůstřelné, to je snad jasné. Mohou stále vznikat chyby, ale díky bodu dva by neměl být problém opakovat zprávy když je to potřeba.

Re:Uváznutí v Aktor systému
« Odpověď #32 kdy: 20. 10. 2019, 03:05:23 »
Předpokládejme dva aktory A a B.
A -> B: kolik je hodin
B -> A: 19:41
A -> B: supr, díky
B -> A: není zač

IMHO je čisté řešení rozšířit zprávy OK na několik zpráv s tím, že některé zprávy budou terminální (konečné) a při jejich obdržení se ukončí komunikační transakce. Pokud jde o nějaký systém pro výpočty, pak budou aktoři asi nějací workeři. Ti workeři se budou nalézat v různých stavech a zprávy budou emitované při změně jejich stavu. Na odběr zprávy se budou moci registrovat další workeři, zajišťující třeba navazující výpočty. Pak si lze nakreslit všechny stavy, které může výpočet mít (všechny výpočty mohou mít buď totožnou množinu stavů anebo se množina stavů může odlišova podle prováděného výpočtu). Pokud jsou známy všechny stavy, lze si znázornit povolené přechody mezi těmi stavy a z toho lze pak vidět, kde vzniká cyklus a zda ten cyklus je žádoucí. Pokud žádoucí není, napojí se do cyklu exit vedoucí na nějaký terminální stav - například při dosažení nějakého čítače, nebo při překročení časového timeoutu apod.

V případě že jde o komunikaci jen dvou aktorů, je situace podobná. Pokud je vyžadováno potvrzení, jde o transakční chování a to opět znamená držet stav a vyřešit všechny možné okrajové situace (latence při přenosu zpráv, zprávy přijdou v opačném pořadí, zpráva přijde poškozená, duplicitně nebo vůbec, dojde pamět k držení stavu, je nutno řešit životnost stavu, ... atd).

Vždy je dobré se inspirovat v reálném světě - jak si zprávy předávají lidé s jednosměrnou vysílačkou? Používají konvenční signalizaci pomocí slov jako: přepínám... opakuji... rozumím... konec. Taky se lze podívat na síťové komunikační protokoly s handshakem, s retransmisí... Nebo se podívat na oběh dokumentů na úřadě - jsou tam také lhůty pro reakci, je určeno kdo to má všechno a v jakém pořadí schválit a orazítkovat, je tam lhůta na promlčení atd. - dokonce tam může dojít i k tomu zacyklení :-D

Zpátky k jednoduchému případu hodin. Místo OK - OK bude víc potvrzovacích zpráv rozlišujících, kdo co potvrzuje. Tím cyklus zmizí - vznikl pouze nedostatečným rozlišením zpráv. Například:

Citace
A->B: kolik je hodin?
B->A: je 10.30h
A->B: potvrzuji přijetí času 10.30h
B->A: díky za potvrzení, transakce dokončena

Pokud A nepotvrdí přijetí, může B poslat odpověď znova:

Citace
...
B->A: opakuji, je 10.30h
A->B: potvrzuji přijetí času 10.30h
B->A: díky za potvrzení, transakce dokončena

Nemá smysl, aby A ještě dál potvrzoval, že dostal od B potvrzení o tom, že A obdržel čas, na který se Bčka ptal.

U distribuovaných transakcí to může být složitější, tam může několik uzlů potvrzovat různé skutečnosti a teprv při splnění všech požadovaných podmínek dojde k uplatnění výsledné akce. Pokud budete mí ale výpočetní grid a budou mezi výpočty závislosti, budete to asi také řešit.

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Uváznutí v Aktor systému
« Odpověď #33 kdy: 20. 10. 2019, 14:19:39 »

Re:Uváznutí v Aktor systému
« Odpověď #34 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á :)


Re:Uváznutí v Aktor systému
« Odpověď #35 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.

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Uváznutí v Aktor systému
« Odpověď #36 kdy: 20. 10. 2019, 23:16:35 »
Díky za příspěvek.

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).

Ano, takhle se klidně můžem bavit.

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.

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.

(Přičemž beru v potaz, co jsi k tomu už napsal. Jen se snažím vysvětlit svůj dotaz, když se evidentně tak blbě vyjadřuju.)

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Uváznutí v Aktor systému
« Odpověď #37 kdy: 20. 10. 2019, 23:55:56 »
uvažuj nad ním jako nad protokolem

Tohle je dobrej hint.

Re:Uváznutí v Aktor systému
« Odpověď #38 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š.

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Uváznutí v Aktor systému
« Odpověď #39 kdy: 21. 10. 2019, 09:00:08 »
Žádná předběžná analýza kódu se v tomhle případě prostě nedělá.
Ehm, já žádnou předběžnou analýzu dělat nechtěl. Alespoň ne nutně.

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.
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.

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š.

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

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

Re:Uváznutí v Aktor systému
« Odpověď #40 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 :)

Re:Uváznutí v Aktor systému
« Odpověď #41 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.

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Uváznutí v Aktor systému
« Odpověď #42 kdy: 21. 10. 2019, 18:09:46 »
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".

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ší.

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.
Jak to myslíš víc jak jednoho klienta?


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...)
Moje představa je, že se všechny data, úplně všechna posílají přes zprávy. Sdílená paměť by byl jakoze side-effect. Ale k tomu jsem se ještě nedopracoval.

Re:Uváznutí v Aktor systému
« Odpověď #43 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á.
« Poslední změna: 21. 10. 2019, 20:12:31 od Mirek Prýmek »

Re:Uváznutí v Aktor systému
« Odpověď #44 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ší.