Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, LaPerouse, Вы писали:
_>>>Конечно не представляю. ))) Я же не расставляю конечные автоматы по всему коду и по любому поводу. LP>>Я тебе верю. Ты похоже вообще слабо представляешь, что такое конечный автомат.
_>Конечный автомат — это полезный инструмент, но не имеющий никакого отношения к вопросам многопоточности, асинхронного кода, сопрограммам и т.п. )
До такой степени не имеет, что _любой_ актор является конечным автоматом просто по определению.
Мне кажется, что я повторяю букварные определения. Не хочется тратить время на написание таких очевидных вещей, но видимо, придется это сделать.
Итак, имеем:
1. Актор имеет состояние
2. Актор принимает входные символы (сообщения)
3. При поступлении сообщения актор переходит в новое состояние, которое зависит от поступившего сообщения и текущего состояния
Если заменить в этих пунктах слово "актор" на "конечный автомат", получим букварное определение КА.
Использование конечного автомата для описания поведения актора является _рекомендуемым_ для akka.
Другая известная в мире С++ реализация акторов SObjectizer (разрабатываемая eao из этого форума) также использует конечные автоматы для реализации акторов.
_>Вся указанная логика легко кодируется в несколько строк: _>
Я пробовал разные DSL для описания конечных автоматов. В java их вагон. Однако, другие разработчики,как это не странно, были не в восторге от этих фреймворков. Уверяю тебя, для человека, который будет поддерживать код, который ты привел, изначальная форма при всей ее уродливости намного понятнее. Испробовано несколько раз.
_>Но только при условие, что State1, State1_Processed, State2, State2_Processed — это состояния полученные из предметной области. А не очередные последствия кривой многопоточности — тогда и от них надо избавляться.
Ну разумеется, это состояния из предметной области. Разве ты видишь, что они непосредственно связаны с запросами?
_>Причём самое интересно, что к теме акторов это всё уже не имеет никакого отношения. Все эти предметные состояния и конечные автоматы были показаны только для смешного впаривания. Потому как если мы посмотрим на предлагаемый вариант работы без акторов, то увидим, что там пропадают не только никчемные состояния, появившиеся вроде как из-за акторов (а на самом деле из-за криворукости), но и предметные. Т.е. эти два примера кода не имеют между собой ничего общего.
Нда. Я ввел эти состояния специально для того, чтобы продемонстрировать, что обработка ответов зависит от состояния, в котором находится автомат (актор) в момент прихода этих ответов. В синхронном случае нет никакой необходимости в ведении этих состояний, потому что сеанс запрос-ответ атомарный и состояние во время выполнения запроса измениться не может. В актор же между запросом и ответом могут приходить любые сообщения, которые могут переводить актор в различные состояния. Если бы имел хотя бы небольшой опыт написания акторного кода, ты бы понял, о чем идет речь. Если введение данных состояний кажется тебе надуманной несмотря на эти пояснения, читай про пример из реального проекта, приведенный ниже.
_>Если же мы попробуем написать на акторах аналог предложенного кода на future (т.е. без всяких State1, State2), то увидим: _>
Даже в случае предельного упрощения ситуации путем выкидывания состояний, этот код все равно не правильный. Если Data1 придет без запроса, сообщение не будет обработано. Это между прочим тривиальнейший случай и встречается на каждом шагу. Приведу пример, приближенный к реальному, — рассмотрим два актора, первый — комната для онлайн игры, второй — игра в комнате. Комната может остановить игру путем посылки сообщения игре StopGame и получит в ответ от игры после остановки GameStopped. При этом игра может остановиться сама по себе (например, игру покинули все игроки или просто нашелся победитель). В этом случае GameStopped придет по событию остановки игры, без всякого запроса StopGame со стороны комнаты. Эти случае должны быть обработаны совершенно различным способом, потому что в случае остановки игры по инициативе комнаты комната должна после получения сообщения GameStopped разослать системные сообщения о принудительной остановке игры и произвести запись в лог (ибо это не характерная ситуация — игроки не смогли доигать до конца). В случае самостоятельной остановки игры комната просто удалит игру. Кстати, даже на таком примитивном примере можно продемонстрировать, каким образом может появиться зависимость от состояний. Комната может затребовать остановку игры по самым различным причинам. Рассмотрим две причины — удаление комнаты (очевидно, перед удалением игра в ней должна быть остановлена) и остановку сервера (сервер рассылает всем комнатам сообщения деинициализации). Обработка сообщения GameStopped зависит от причины остановки! Если остановка игры была вызвана удалением комнаты, необходимо после получения подтверждения об остановке игры и записей в лог подготовить комнату к удалению и послать сообщение серверу, что комната готова к удалению. В случае остановки сервера нужно просто произвести деинициализацию. Это один в один случай из моего примера. В реальных акторах совокупность возможных состояний и сообщений может быть таковой, что без формализации актора в виде конечного автомата будет потерян всякий контроль над происходящим. Повторюсь, мне не пришлось бы тебе это объяснять, если бы у тебя был хотя бы минимальный опыт написания акторов. Я занимаюсь этим уже два года, за которые успел повидать разные сценарии работы с акторами, как правильные,так и неправильные, поэтому могу делать определенные выводы о том, как акторы писать можно, а как нельзя. Так вот, большинство правильно написанных акторов были реализованы при помощи конечных автоматов. Поэтому я могу понять, почему разработчики акторных фреймворков всегда дополняют инструментарий дополнительной поддержкой конечных автоматов.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[13]: Об очередном антипаттерне. Модель акторов.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, LaPerouse, Вы писали:
S>>>Разумеется, это не значит, что на голый await стоит натягивать акторы. LP>>В Unity3d натянули на yield return null. Правда, не акторы, а автоматный код скриптов. S>Угу, это не совсем акторы.
S>Акторы предполагают, во-первых, декларативное описание ч/з комбинацию состояние-входы-выходы.
Декларативное описание? Это где такое требование?
S>Во-вторых, свою модель вычислений (с immutable-данными + pure-функциями).
Не совсем понятно, что под этим имеется ввиду. Каждый актор имеет свое локальное состояние, и оно, разумеется, мутабельное. Другое дело, что актор не должен разделять изменяемое состояние с другими акторами.
S>А, да, всю эту кухню конечно можно спрятать за await, но менее главной она от этого не станет.
await вообще параллельно к самой концепции актора. Это способ упрощения его реализации путем линеаризации кода. Я ведь приводил пример с актором Player ниже по ветке.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[19]: Об очередном антипаттерне. Модель акторов.
Здравствуйте, Mamut, Вы писали:
F>>т.е. эрланговские акторы без gen_event'а уже не акторы?
M>Акторы, акторы.
M>Главное отличие Эрланга — прагматичный подход. Если теория говорит, что «функциональный язык должен быть чистым», а «акторы должны декларативно задаваться», Эрланг смотрит на это с легким недоумением и презрением, а потом реализует то, что наиболее рпактично в реальном мире.
Актор не должен декларативно задаваться. Впрочем, под декларативностью люди понимают разные вещи, для кого-то и ФП декларативно.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[13]: Об очередном антипаттерне. Модель акторов.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, LaPerouse, Вы писали:
LP>>Как можно видеть конечный автомат при помощи сопрограмм реализован без введения трех явных состояний.
F>скорее над этим находятся другие состояния поведения.
Эти три состояния тоже неявно присутствуют. Их втыкает языковая реализация yield return.
F>а промежуточные состояния атаки часто и не нужны.
Это просто пример. Кстати, почему не нужны, атака может быть серией ударов.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[14]: Об очередном антипаттерне. Модель акторов.
Здравствуйте, so5team, Вы писали:
S>Может быть вовсе и не так. А вот так: S>
S>// Описание связей.
S>fsmState.in(WAIT_FOR_RESPONSE1).event(calc1);
S>fsmState.in(WAIT_FOR_RESPONSE2).event(calc2);
S>fsmState.in(NO_REQUEST).event(processEvent);
S>
S>Т.е. обслуживание конечного автомата актора является одной из задач фреймворка, реализующего Actor Model. То, что в Akka/Scala этого нет не означает ущербности ActorModel.
В акка как раз это есть. Только конечный автомат как его не украшай, останется конечным автоматом. Если бы накладные расходы от КА можно было бы нивелировать красивым фреймворком, весь геймдев не двигался бы от КА к behaviour tree и сопрограммам.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[14]: Об очередном антипаттерне. Модель акторов.
Здравствуйте, LaPerouse, Вы писали:
LP>Эти три состояния тоже неявно присутствуют. Их втыкает языковая реализация yield return. LP>Это просто пример. Кстати, почему не нужны, атака может быть серией ударов.
это уже следующий уровень вложенности. на каждом только то, что необходимо для этого действия. так проще.
в верхние состояния тащить это нет смысла.
...coding for chaos...
Re[15]: Об очередном антипаттерне. Модель акторов.
Здравствуйте, LaPerouse, Вы писали:
LP>До такой степени не имеет, что _любой_ актор является конечным автоматом просто по определению.
обоснования?
актор может не менять поведение в зависимости от состояния и при этом оставаться актором. а может и состояния не менять.
LP>Приведу пример, приближенный к реальному, — рассмотрим два актора, первый — комната для онлайн игры, второй — игра в комнате. Комната может остановить игру путем посылки сообщения игре StopGame и получит в ответ от игры после остановки GameStopped. При этом игра может остановиться сама по себе (например, игру покинули все игроки или просто нашелся победитель). В этом случае GameStopped придет по событию остановки игры, без всякого запроса StopGame со стороны комнаты. Эти случае должны быть обработаны совершенно различным способом, потому что в случае остановки игры по инициативе комнаты комната должна после получения сообщения GameStopped разослать системные сообщения о принудительной остановке игры и произвести запись в лог (ибо это не характерная ситуация — игроки не смогли доигать до конца).
во всех случаях достаточно сказать серверу ойвсё(успешно/ниочинь, результаты);
LP>В случае самостоятельной остановки игры комната просто удалит игру.
игра удаляется в любом случае.
LP>Рассмотрим две причины — удаление комнаты (очевидно, перед удалением игра в ней должна быть остановлена) и остановку сервера (сервер рассылает всем комнатам сообщения деинициализации). Обработка сообщения GameStopped зависит от причины остановки! Если остановка игры была вызвана удалением комнаты, необходимо после получения подтверждения об остановке игры и записей в лог подготовить комнату к удалению и послать сообщение серверу, что комната готова к удалению. LP>В случае остановки сервера нужно просто произвести деинициализацию.
во всех случаях достаточно облить бензином и поджечь.
LP>Я занимаюсь этим уже два года, за которые успел повидать разные сценарии работы с акторами, как правильные,так и неправильные, поэтому могу делать определенные выводы о том, как акторы писать можно, а как нельзя.
почему тогда у тебя получается так сложно?
...coding for chaos...
Re[15]: Об очередном антипаттерне. Модель акторов.
Здравствуйте, LaPerouse, Вы писали:
S>>Т.е. обслуживание конечного автомата актора является одной из задач фреймворка, реализующего Actor Model. То, что в Akka/Scala этого нет не означает ущербности ActorModel.
LP>В акка как раз это есть.
Можете показать?
LP> Только конечный автомат как его не украшай, останется конечным автоматом.
КА есть КА и применение КА не всегда уместно. Как и попытки заменить КА сопрограмами. Только это вовсе не означает, что Actor Model является антипатерном.
LP> Если бы накладные расходы от КА можно было бы нивелировать красивым фреймворком, весь геймдев не двигался бы от КА к behaviour tree и сопрограммам.
Аргумент из категории "миллионы мух..."
Re[15]: Об очередном антипаттерне. Модель акторов.
LP>Это что касается теории. На практике _каждая_ известная мне реализация акторов имеет в своем составе ДСЛ для определения конечного автомата LP>Вот для AKKA: LP>http://doc.akka.io/docs/akka/snapshot/scala/fsm.html
1. Какие тебе реализации акторов известны?
2. fsm в akka напрямую взят из библиотеки Erlang'а, потому что создание конечных автоматов является часто встречающейся задачей, и для нее в Erlang'е сделано общее решение. Так же в эрланге есть общие решения для серверов, событий и супервизоров: потому что это — часто встречающиеся паттерны, и почему бы не реализовать что-то, часто встречающееся.
И да, (gen_)fsm — самый редко используемых из всех.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, LaPerouse, Вы писали:
LP>>До такой степени не имеет, что _любой_ актор является конечным автоматом просто по определению.
F>обоснования?
Обоснование там же.
F>актор может не менять поведение в зависимости от состояния и при этом оставаться актором. а может и состояния не менять.
Конечно, может. Но подавляющее кол-во акторов таки меняют. И не нужно кивать на неправильное проектирование, я видел достаточно акторного кода, написанного хорошими специалистами в многопоточности.
LP>>Приведу пример, приближенный к реальному, — рассмотрим два актора, первый — комната для онлайн игры, второй — игра в комнате. Комната может остановить игру путем посылки сообщения игре StopGame и получит в ответ от игры после остановки GameStopped. При этом игра может остановиться сама по себе (например, игру покинули все игроки или просто нашелся победитель). В этом случае GameStopped придет по событию остановки игры, без всякого запроса StopGame со стороны комнаты. Эти случае должны быть обработаны совершенно различным способом, потому что в случае остановки игры по инициативе комнаты комната должна после получения сообщения GameStopped разослать системные сообщения о принудительной остановке игры и произвести запись в лог (ибо это не характерная ситуация — игроки не смогли доигать до конца).
F>во всех случаях достаточно сказать серверу ойвсё(успешно/ниочинь, результаты);
LP>>В случае самостоятельной остановки игры комната просто удалит игру.
F>игра удаляется в любом случае.
Разумеется. Об этом и речь — есть общая част логики, есть раздельная.
LP>>Рассмотрим две причины — удаление комнаты (очевидно, перед удалением игра в ней должна быть остановлена) и остановку сервера (сервер рассылает всем комнатам сообщения деинициализации). Обработка сообщения GameStopped зависит от причины остановки! Если остановка игры была вызвана удалением комнаты, необходимо после получения подтверждения об остановке игры и записей в лог подготовить комнату к удалению и послать сообщение серверу, что комната готова к удалению. LP>>В случае остановки сервера нужно просто произвести деинициализацию. F>во всех случаях достаточно облить бензином и поджечь.
Приведи пример реализации описанного сценария. Только с учетом того, что комната и игра являются акторами.
LP>>Я занимаюсь этим уже два года, за которые успел повидать разные сценарии работы с акторами, как правильные,так и неправильные, поэтому могу делать определенные выводы о том, как акторы писать можно, а как нельзя. F>почему тогда у тебя получается так сложно?
Приведенный пример взят из успешного проекта с десятилетней историей, написанный специалистами в многопоточном программировании, сделанный на их же собственном акторном фреймворке, написанном специально для проекта.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[16]: Об очередном антипаттерне. Модель акторов.
Здравствуйте, Mamut, Вы писали:
LP>>Это что касается теории. На практике _каждая_ известная мне реализация акторов имеет в своем составе ДСЛ для определения конечного автомата LP>>Вот для AKKA: LP>>http://doc.akka.io/docs/akka/snapshot/scala/fsm.html
M>1. Какие тебе реализации акторов известны?
В основном, внутренние реализации, специфичные для проектов. Видел две более-менее удачные реализации для С++ и одну — для java.
Из публичных мне известны akka и sobjectizer
M>2. fsm в akka напрямую взят из библиотеки Erlang'а, потому что создание конечных автоматов является часто встречающейся задачей, и для нее в Erlang'е сделано общее решение. Так же в эрланге есть общие решения для серверов, событий и супервизоров: потому что это — часто встречающиеся паттерны, и почему бы не реализовать что-то, часто встречающееся.
M>И да, (gen_)fsm — самый редко используемых из всех.
Так не понял, часто используемый или редко используемый?
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[17]: Об очередном антипаттерне. Модель акторов.
Здравствуйте, LaPerouse, Вы писали:
LP>>>До такой степени не имеет, что _любой_ актор является конечным автоматом просто по определению. F>>обоснования? LP>Обоснование там же.
нет там его.
F>>актор может не менять поведение в зависимости от состояния и при этом оставаться актором. а может и состояния не менять. LP>Конечно, может.
и к чему тогда был пассаж про "КА по определению" ?
LP>Но подавляющее кол-во акторов таки меняют.
не вижу такого. покажи.
LP>И не нужно кивать на неправильное проектирование, я видел достаточно акторного кода, написанного хорошими специалистами в многопоточности.
ммм... и что с того?
LP>>>В случае самостоятельной остановки игры комната просто удалит игру. F>>игра удаляется в любом случае. LP>Разумеется. Об этом и речь — есть общая част логики, есть раздельная.
нет никакой необходимости разделять. удалилась и удалилась.
F>>во всех случаях достаточно облить бензином и поджечь. LP>Приведи пример реализации описанного сценария. Только с учетом того, что комната и игра являются акторами.
я же написал. в случае любого завершения игры она просто присылает результаты со статусом завершения.
F>>почему тогда у тебя получается так сложно? LP>Приведенный пример взят из успешного проекта с десятилетней историей, написанный специалистами в многопоточном программировании, сделанный на их же собственном акторном фреймворке, написанном специально для проекта.
печально звучит.
...coding for chaos...
Re[17]: Об очередном антипаттерне. Модель акторов.
M>>2. fsm в akka напрямую взят из библиотеки Erlang'а, потому что создание конечных автоматов является часто встречающейся задачей, и для нее в Erlang'е сделано общее решение. Так же в эрланге есть общие решения для серверов, событий и супервизоров: потому что это — часто встречающиеся паттерны, и почему бы не реализовать что-то, часто встречающееся.
M>>И да, (gen_)fsm — самый редко используемых из всех.
LP>Так не понял, часто используемый или редко используемый?
Самый редко используемый из часто используемых. То есть так: создание FSM — это достаточно общая задача, чтобы сделать для нее общее решение. Но из всех общих решений FSM — самый редко используемый. gen_server используется чаще на несколько десятичных порядков, например.
FSM нужен для создания FSM. Сказки про то, что каждый актор — это FSM оставим сказочникам.
ЗЫ. Скачал тут себе распределенную базу данных Riak, реализованную на Erlang'е. Скачал все ее зависимости, тоже на Erlang'е. То есть, казалось бы, код, в котором FSM просто обязан быть. И даже тут fsm — на последнем месте.
Здравствуйте, LaPerouse, Вы писали:
_>>Конечный автомат — это полезный инструмент, но не имеющий никакого отношения к вопросам многопоточности, асинхронного кода, сопрограммам и т.п. ) LP>До такой степени не имеет, что _любой_ актор является конечным автоматом просто по определению.
Смотрю сюда https://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%B0%D0%BA%D1%82%D0%BE%D1%80%D0%BE%D0%B2 и не вижу ничего подобного.
LP>Мне кажется, что я повторяю букварные определения. Не хочется тратить время на написание таких очевидных вещей, но видимо, придется это сделать. LP>Итак, имеем: LP>1. Актор имеет состояние LP>2. Актор принимает входные символы (сообщения) LP>3. При поступлении сообщения актор переходит в новое состояние, которое зависит от поступившего сообщения и текущего состояния
Самое забавное, что тот мой пример (с запуском скачивания файла в отдельном потоке и возврате результата через сообщение) вполне укладывается в определение по моей ссылке выше, но не имеет ничего общего с данными пунктами. )))
LP>Если заменить в этих пунктах слово "актор" на "конечный автомат", получим букварное определение КА.
Вот вот, это собственно оно и есть. ))) Только опять же непонятно причём тут вообще акторы? )
LP>Это что касается теории. На практике _каждая_ известная мне реализация акторов имеет в своем составе ДСЛ для определения конечного автомата LP>Вот для AKKA: LP>http://doc.akka.io/docs/akka/snapshot/scala/fsm.html
Библиотека boost имеет в своём составе DSL для реализации конечного автомата. Означает ли это, что любое приложение с использованием boost'a должно включать в себя конечный автомат? )
LP>Я пробовал разные DSL для описания конечных автоматов. В java их вагон. Однако, другие разработчики,как это не странно, были не в восторге от этих фреймворков. Уверяю тебя, для человека, который будет поддерживать код, который ты привел, изначальная форма при всей ее уродливости намного понятнее. Испробовано несколько раз.
Вообще то в данном коде главное не используемый DSL (мне так просто удобнее было записывать), а выкидывание ненужных состояний, введённых для демонстрации неудобства модели акторов. )))
Кстати говоря, вообще очень странно, что при таком большом опыте работы с КА (по твоим словам), ты не в курсе такой базовой вещи как guard, которая прямо напрашивалась в данном примере, вместо размножения никчемных состояний.
LP>Нда. Я ввел эти состояния специально для того, чтобы продемонстрировать, что обработка ответов зависит от состояния, в котором находится автомат (актор) в момент прихода этих ответов. В синхронном случае нет никакой необходимости в ведении этих состояний, потому что сеанс запрос-ответ атомарный и состояние во время выполнения запроса измениться не может. В актор же между запросом и ответом могут приходить любые сообщения, которые могут переводить актор в различные состояния. Если бы имел хотя бы небольшой опыт написания акторного кода, ты бы понял, о чем идет речь. Если введение данных состояний кажется тебе надуманной несмотря на эти пояснения, читай про пример из реального проекта, приведенный ниже.
На самом деле вся твоя демагогия в данной темке строится на очень простой уловке: ты сравниваешь инструменты на решение разных задач, а не одной. У нас могут быть следующие сценарии:
1. Исполнение только указанной последовательности команд в данный момент времени
2. Возможное параллельное исполнение каких-то других последовательностей команд, причём влияющих на поведение первой
Ты тут сравниваешь реализацию случая 1 на future с реализацией случая 2 на акторах и делаешь вывод о более удобном коде на future? Смешно. Давай поглядим что будет, если играть по честному.
Если сравнивать реализации для случая 1, то я уже привёл примеры соответствующих акторов. Как видно, они имеют одинаковый объём кода и читаемость с реализацией на future. И незачем придумывать тут какие-то "любые сообщения, которые могут переводить актор в различные состояния" — их нет по условию задачи.
Если же сравнивать реализации для случая 2, то они безусловно становятся сложнее. Но я легко приведу их тебе. Правда только после того, как увижу твою реализацию данного случая на future. Т.е. когда параллельно с твоим кодом "process(future1.get(), future2.get());" должен выполняться ещё какой-то код, причём меняющий состояние системы так, что должен меняться результат обработки.
LP>Я занимаюсь этим уже два года, за которые успел повидать разные сценарии работы с акторами, как правильные,так и неправильные, поэтому могу делать определенные выводы о том, как акторы писать можно, а как нельзя. Так вот, большинство правильно написанных акторов были реализованы при помощи конечных автоматов. Поэтому я могу понять, почему разработчики акторных фреймворков всегда дополняют инструментарий дополнительной поддержкой конечных автоматов.
Да, уже хорошо видно, что у тебя все выводы основаны на впечатлениях из твоего уютненького маленького мирка. В котором, если уж используют актор, то исключительно огромные, с десятками входных сообщений. Но не стоит думать, что и весь мир устроен точно так же. )
Re[15]: Об очередном антипаттерне. Модель акторов.
Здравствуйте, LaPerouse, Вы писали:
LP>Другая известная в мире С++ реализация акторов SObjectizer также использует конечные автоматы для реализации акторов.
Здравствуйте, alex_public, Вы писали:
_>>>Конечный автомат — это полезный инструмент, но не имеющий никакого отношения к вопросам многопоточности, асинхронного кода, сопрограммам и т.п. ) LP>>До такой степени не имеет, что _любой_ актор является конечным автоматом просто по определению.
_>Смотрю сюда https://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%B0%D0%BA%D1%82%D0%BE%D1%80%D0%BE%D0%B2 и не вижу ничего подобного.
Ты свою ссылку то открывал ? "выбрать тип поведения, которое будет использоваться для следующего сообщения в свой адрес.".
_>Самое забавное, что тот мой пример (с запуском скачивания файла в отдельном потоке и возврате результата через сообщение) вполне укладывается в определение по моей ссылке выше, но не имеет ничего общего с данными пунктами. )))
В чистом виде конечный автомат, только ты его пишешь обычным кодом.
