Здравствуйте, LaPerouse, Вы писали:

LP>Actor:
LP>

LP>if (state == 1) {
LP>    fsmState = WAIT_FOR_RESPONSE1;
LP>    call(request1);
LP>}
LP>else if (state == 2) {
LP>    fsmState = WAIT_FOR_RESPONSE2;
LP>    call(request2);
LP>}

LP>//Обработка
LP>void messageReceived(Response response) {
LP>    if (fsmState == WAIT_FOR_RESPONSE1)
LP>        calc1(response);
LP>    else if (fsmState == WAIT_FOR_RESPONSE2)
LP>        calc2(response);
LP>    else if (fsmState == NO_REQUEST)//здесь сообщение Response пришло без Request
LP>        processEvent(response);
LP>}
LP>

Может быть вовсе и не так. А вот так:

// Описание связей.
fsmState.in(WAIT_FOR_RESPONSE1).event(calc1);
fsmState.in(WAIT_FOR_RESPONSE2).event(calc2);
fsmState.in(NO_REQUEST).event(processEvent);

Т.е. обслуживание конечного автомата актора является одной из задач фреймворка, реализующего Actor Model. То, что в Akka/Scala этого нет не означает ущербности ActorModel.

Здравствуйте, LaPerouse, Вы писали:


S>>Разумеется, это не значит, что на голый await стоит натягивать акторы.
LP>В Unity3d натянули на yield return null. Правда, не акторы, а автоматный код скриптов.
Угу, это не совсем акторы.

Акторы предполагают, во-первых, декларативное описание ч/з комбинацию состояние-входы-выходы.
Во-вторых, свою модель вычислений (с immutable-данными + pure-функциями).
Во-третьих, полноценный рантайм для шедулинга/обработки ошибок/отката/etc.
В четвёртых, прозрачное масштабирование от мобильника до облака.

ну и тыды и тыпы.
Без всего этого акторы использовать можно, но, за редким исключением, всегда найдётся более простое и удобное решение.

А, да, всю эту кухню конечно можно спрятать за await, но менее главной она от этого не станет.

Здравствуйте, Sinix, Вы писали:

S>Без всего этого акторы использовать можно, но, за редким исключением, всегда найдётся более простое и удобное решение.

а хоть где-нибудь они вообще реализованы?

Здравствуйте, BulatZiganshin, Вы писали:

S>>Без всего этого акторы использовать можно, но, за редким исключением, всегда найдётся более простое и удобное решение.

BZ>а хоть где-нибудь они вообще реализованы?
Эрланг, MS orleans, с натяжкой скала.
Плюс куча невыстреливших прототипов внутри MS research. Как минимум in-out contracts в Singularity и COmega/Axum/Ms robotics CCR.

Здравствуйте, Sinix, Вы писали:

S>>>Без всего этого акторы использовать можно, но, за редким исключением, всегда найдётся более простое и удобное решение.
BZ>>а хоть где-нибудь они вообще реализованы?
S>Эрланг

смотрим:
> Акторы предполагают, во-первых, декларативное описание ч/з комбинацию состояние-входы-выходы.

этого в эрланге нет

> В четвёртых, прозрачное масштабирование от мобильника до облака.

этого тоже. таким образом, эрланг — неподходящий язык для использования акторов?

Здравствуйте, alex_public, Вы писали:

_>Здесь имелось в виду что-то рукопашное, типа примеров в первом сообщение темки. А async/await из C# — это всё же сопрограмма, а не конечный автомат (пусть даже она и реализована через него внутри). Собственно если мы например переделаем в следующей версии C# реализацию async/await через stackfull coroutine, то скорее всего никто этого и не заметит. )))

Скорее всего бОльшая часть программ тупо перестанет работать, потому что stackfull, внезапно, дает возможность, ну например, повторно войти в принципиально нереэнтерабельный участок кода. Ну вот блокирующее чтение из стрима. Глобальные ресурсы пока еще никто не отменял. Опаньки !

Здравствуйте, BulatZiganshin, Вы писали:

>> Акторы предполагают, во-первых, декларативное описание ч/з комбинацию состояние-входы-выходы.
BZ>этого в эрланге нет
Весь gen_event же.

>> В четвёртых, прозрачное масштабирование от мобильника до облака.
Слышал как минимум про две софтины с общим кодом на эрланге для сервера и клиента на мобильнике. Если не врут, то поддержка андроида в Erlang/OTP прям из коробки была. Так что с натяжкой, но есть.

Здравствуйте, Ikemefula, Вы писали:

I>Скорее всего бОльшая часть программ тупо перестанет работать, потому что stackfull, внезапно, дает возможность, ну например, повторно войти в принципиально нереэнтерабельный участок кода.
Так это не столько к await, сколько ко всему коду, написанному без учёта реэнтерабельности.
Ну, т.е. поломается и без await-а

Здравствуйте, Sinix, Вы писали:

I>>Скорее всего бОльшая часть программ тупо перестанет работать, потому что stackfull, внезапно, дает возможность, ну например, повторно войти в принципиально нереэнтерабельный участок кода.
S>Так это не столько к await, сколько ко всему коду, написанному без учёта реэнтерабельности.
S>Ну, т.е. поломается и без await-а

Поломается из за применения любой stackfull короутины, действительно, без разницы, с await или без. Причина именно в стекфулл короутине, она вводит ничем не ограниченую кооперативную многозадачность. Однозадачный код вдруг станет многозадачным.
Реэнтерабельность в нереэнтерабельный участок это частный случай. Куда более вероятен сбой из за нарушения инварианта/протокола любого глобального ресурса, хотя бы и простой переменной.

Здравствуйте, Ikemefula, Вы писали:

I>Скорее всего бОльшая часть программ тупо перестанет работать, потому что stackfull, внезапно, дает возможность, ну например, повторно войти в принципиально нереэнтерабельный участок кода. Ну вот блокирующее чтение из стрима. Глобальные ресурсы пока еще никто не отменял. Опаньки !

для этого нужно чтобы прикладной код ещё и заходил туда. сейчас он этого не делает и автоматом делать этого не станет. с таким же успехом иожно ожидать что добавление библиотеки Thread поломает старые однопоточные программы, даже если они её не вызывают

Здравствуйте, alex_public, Вы писали:

_>Конечный автомат — это полезный инструмент, но не имеющий никакого отношения к вопросам многопоточности, асинхронного кода, сопрограммам и т.п. )

Конечный автомат имеет самое непосредственное отношение к многопоточности и асинхронному коду. Начинать можно от верификации и симуляции многопоточных программ.

Можно открыть эту книгу на восьмой главе. Или вот, например.

Здравствуйте, BulatZiganshin, Вы писали:

BZ>для этого нужно чтобы прикладной код ещё и заходил туда. сейчас он этого не делает и автоматом делать этого не станет. с таким же успехом иожно ожидать что добавление библиотеки Thread поломает старые однопоточные программы, даже если они её не вызывают

Наоборот, именно это прикладной код и делает. От тебя мало что будет зависеть. Вот ты ожидаешь, что чтение из стрима блокирующее, у тебя один поток, потому упрощаешь себе жизнь. Скажем, в однозадачном приложении никто не утруждает себя телодвижениями "а вдруг через 5 лет здесь появится многозадачность"

Теперь фокус — ктото взял и запустил твой код во втором потоке. Вопрос — чего ожидать.
Собтсвенно непонятно, почему в случае со Stackfull короутинами будет как то иначе ?

Здравствуйте, Ikemefula, Вы писали:

BZ>>для этого нужно чтобы прикладной код ещё и заходил туда. сейчас он этого не делает и автоматом делать этого не станет. с таким же успехом иожно ожидать что добавление библиотеки Thread поломает старые однопоточные программы, даже если они её не вызывают

I>Наоборот, именно это прикладной код и делает. От тебя мало что будет зависеть. Вот ты ожидаешь, что чтение из стрима блокирующее, у тебя один поток, потому упрощаешь себе жизнь. Скажем, в однозадачном приложении никто не утруждает себя телодвижениями "а вдруг через 5 лет здесь появится многозадачность"

I>Теперь фокус — ктото взял и запустил твой код во втором потоке. Вопрос — чего ожидать.
I>Собтсвенно непонятно, почему в случае со Stackfull короутинами будет как то иначе ?

потому что код и так уже работает во втором потоке. только теперь короутина стала поддерживать переключение из вложенных выховов. но сами по себе они от добавления этой поддержки не появятся

Здравствуйте, BulatZiganshin, Вы писали:

I>>Теперь фокус — ктото взял и запустил твой код во втором потоке. Вопрос — чего ожидать.
I>>Собтсвенно непонятно, почему в случае со Stackfull короутинами будет как то иначе ?

BZ>потому что код и так уже работает во втором потоке. только теперь короутина стала поддерживать переключение из вложенных выховов.

Правильно — как только вводится второй поток или вторая задача, вся стройная концепция быстро рушится.

>но сами по себе они от добавления этой поддержки не появятся

И ежу понятно. Валится не от добавления либы, а от того что ты сделаешь код многозадачным. Представь себе бутерброд:

твой код вызывает сторонний фремворк который вызывает твой стрим. Ты, внезапно, ввел короутины и стрим стал неблокирующим.
Вопрос — откуда фремворку знать, что надо как то иначе работать с глобальными ресурсами ?

Здравствуйте, Ikemefula, Вы писали:

I>Правильно — как только вводится второй поток или вторая задача, вся стройная концепция быстро рушится.

ты потерял суть спора

Здравствуйте, BulatZiganshin, Вы писали:

I>>Правильно — как только вводится второй поток или вторая задача, вся стройная концепция быстро рушится.

BZ>ты потерял суть спора

Цитирую: "для этого нужно чтобы прикладной код ещё и заходил туда"

Смотри внимательно, прикладной код быть в обеих ветках, в разное время, но не в обеих одновременно

var oldState = globalResource;
globalResource = new State();
var x = stream.read();  /// вот этот вызов сделаем неблокирующим, шоб сильнее было
... ля-ля-ля
globalResource = oldState;

где то "там"

var oldState = globalResource;
globalResource = new State();
var x = someLongBlockingCall();
... ля-ля-ля
globalResource = oldState;

Теперь, если стрим будет неблокирующим, прикладной код может работать одновременно в обеих ветках.

Здравствуйте, Sinix, Вы писали:

>>> Акторы предполагают, во-первых, декларативное описание ч/з комбинацию состояние-входы-выходы.
BZ>>этого в эрланге нет
S>Весь gen_event же.

т.е. эрланговские акторы без gen_event'а уже не акторы?

>>> В четвёртых, прозрачное масштабирование от мобильника до облака.
S>Слышал как минимум про две софтины с общим кодом на эрланге для сервера и клиента на мобильнике. Если не врут, то поддержка андроида в Erlang/OTP прям из коробки была. Так что с натяжкой, но есть.

я погуглил, но там что-то совсем мутное.
можешь найти адекватный пример?

F>т.е. эрланговские акторы без gen_event'а уже не акторы?

Акторы, акторы.

Главное отличие Эрланга — прагматичный подход. Если теория говорит, что «функциональный язык должен быть чистым», а «акторы должны декларативно задаваться», Эрланг смотрит на это с легким недоумением и презрением, а потом реализует то, что наиболее рпактично в реальном мире.



В итоге да, наверное, чисто с академической точки зрения Эрланг и не шибко функциональный, и не шибко акторный, и не шибко ОО, и... и...

F>я погуглил, но там что-то совсем мутное.
F>можешь найти адекватный пример?

На практике нет ничего. Есть теоретическая возможность запустить или написать что-то на Эрланге для Андроида и iOS, на практике — нет. Это пилят/пилили какие-то энтузиасты. В обозримом будущем на мобильных устройствах Эрланга не будет (другое дело всякий embed, туда его активно впиливают)

Здравствуйте, neFormal, Вы писали:


F>т.е. эрланговские акторы без gen_event'а уже не акторы?
Нет конечно Но НЯП, это как "самурай без меча подобен самураю с мечом, но только без меча". Есть-то оно есть, толку-то?
И на эту тему лучше реальных эрланговодов поспрашивать, я скорее свечку держал
Если ничего не перепутал, из отметившихся в ветке, это как минимум Mamut.

F>я погуглил, но там что-то совсем мутное.
F>можешь найти адекватный пример?
Неа, про эрланг на андроиде с чужих слов, гугль находит что-то типа такого, не больше.

Здравствуйте, Sinix, Вы писали:

S>И на эту тему лучше реальных эрланговодов поспрашивать, я скорее свечку держал
S>Если ничего не перепутал, из отметившихся в ветке, это как минимум Mamut.

понятно. прсто эрланг создан практиками. и это отражается во всём вплоть до стандартной библиотеки. теоретические подходы к нему мало применимы.
а так-то я тоже на нём пишу текущий проект.

F>>я погуглил, но там что-то совсем мутное.
F>>можешь найти адекватный пример?
S>Неа, про эрланг на андроиде с чужих слов, гугль находит что-то типа такого, не больше.

да, видел. но мне показалось мутным.
много чего запускали на андроиде на разных языках, но всё оно, как по мне, выглядит слабо.