кстати, акторы проблему concurrent доступа не решают

в рамках актора решают. а наружу стейт не должен выставляться. аск -- антипаттерн.

@fomkin а не хочешь взять какой-нить disruptor?)

в рамках актора решают. а наружу стейт не должен выставляться. аск -- антипаттерн.

промоуз слать актору это совсем плохо?

промоуз слать актору это совсем плохо?

просто геттеры - зло. с аском тоже самое

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

ну это такой, граничный кейс всё таки

ask по сути

ask по сути

аск вырождается в цепочку асков , то есть у тебя все по цепочке должно идти( до конечной реализации )

ну это такой, граничный кейс всё таки

А как писать реквест-респонс ориентированные приложения на акторах без асков или их подобия? Или "не пишите такие приложения на акторах"?

А как писать реквест-респонс ориентированные приложения на акторах без асков или их подобия? Или "не пишите такие приложения на акторах"?

Ну я как бы вообще не был против ask так то

аск вырождается в цепочку асков , то есть у тебя все по цепочке должно идти( до конечной реализации )

почему? у тебя есть слой акторов, который находится на стыке между акка миром и другим, собственно этот слой уже общается с акторами посредством tell, а не ask

@folexeyy я всё видел :)

мисклик :) Но пак прекрасен, да

А как писать реквест-респонс ориентированные приложения на акторах без асков или их подобия? Или "не пишите такие приложения на акторах"?

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

это перебор)

Ну мы тоже пришли к актору-коллектору. Аски это прям плохо. А реквест-респонс приложения на акторах в целом норм, удобное конкарренси же.

тут как и везде - главное не увлекаться

а как получить данные из актора коллетора?)

а как получить данные из актора коллетора?)

он их уже сам кладёт куда надо

@dos65 промисами-фьючами например

но да, он их сам кладет туда, ты уже не пуллишь

но зачем тебе самому заворачивать промис, если аск за тебя это сделает7)

На моей практики эволюция проектах выглядит так: 1. У нас будут акторы и мы победим конкаренси! 2. Хм. Мне нужны данные из актора А в акторе Б. Давай-ка сделаем запросик из А в Б через аск. 3. Что-то весь проект в асках. Проще было бы использовать геттеры! 4. Акторы -- говно. Надо все переписывать на стримах! 5. ... 6. Фэйл.

но зачем тебе самому заворачивать промис, если аск за тебя это сделает7)

Чтобы цепочку асков не делать например

почему? у тебя есть слой акторов, который находится на стыке между акка миром и другим, собственно этот слой уже общается с акторами посредством tell, а не ask

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

Ну мы тоже пришли к актору-коллектору. Аски это прям плохо. А реквест-респонс приложения на акторах в целом норм, удобное конкарренси же.

Для реквест-респонса аски тоже не подходят, потому что обычно возникает необходимость трекать реквест по логам. По этому так или иначе преходится передавать какой-то RequestId. А если его передавать, то почему бы не передавать адрес получателя вместе с ним.

На моей практики эволюция проектах выглядит так: 1. У нас будут акторы и мы победим конкаренси! 2. Хм. Мне нужны данные из актора А в акторе Б. Давай-ка сделаем запросик из А в Б через аск. 3. Что-то весь проект в асках. Проще было бы использовать геттеры! 4. Акторы -- говно. Надо все переписывать на стримах! 5. ... 6. Фэйл.

подставь сюда любую технологию вместо акторов

подставь сюда любую технологию вместо акторов

поставь сюда мальчика с велосипедом и палкой )

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

не вижу проблемы

Для реквест-респонса аски тоже не подходят, потому что обычно возникает необходимость трекать реквест по логам. По этому так или иначе преходится передавать какой-то RequestId. А если его передавать, то почему бы не передавать адрес получателя вместе с ним.

всё так

Так всетаки Кланговские миниакторы. Какие у них минусы?

не вижу проблемы

ну так как внешний мир спросит ?

@fomkin зачем тебе акторы сдались? тебе ведь непосредственный обмен сообщениями не требуется? тебе ведь наверное просто хочется засинкать выполнение блока кода по определенному ключу (где ключом может быть любой обьект) и при этом не иметь flag.synchronized, поскольку это не гибко, может тормозить общий прогресс, еще и не все нужные случае этим покроешь и т.д.. верно? или я не правильно понял для чего тебе акторы? ))

ты делаешь актору АСК, он дальше делает цепочку теллов , но чтобы получить ответ он должен обработать сообщение , а ты всё ещё с теллом висишь

одним аском

или я неправильно понял фразу цепочка асков

@fomkin зачем тебе акторы сдались? тебе ведь непосредственный обмен сообщениями не требуется? тебе ведь наверное просто хочется засинкать выполнение блока кода по определенному ключу (где ключом может быть любой обьект) и при этом не иметь flag.synchronized, поскольку это не гибко, может тормозить общий прогресс, еще и не все нужные случае этим покроешь и т.д.. верно? или я не правильно понял для чего тебе акторы? ))

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

а какой стейт кроме сессии?

https://monix.io/docs/2x/eval/mvar.html

не достаточно будет?

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

Вообще странно, откуда у тебя там много конкаренси

Так и сделано. Там есть стейт коннекшона, стейт сессии, стейт бриджа, стейт самого приложения. По началу оно нормально управлялось и выглядело, но потом разлослось -- здесь счетчик, там хэшмэп, здесь еще один хэшмэп. Раньше я еще сапортил scala.js версию, по этому AtomicReference нельзя было использовать, в ход пошли волатайлы и тп. Трогать это страшно. Лучше решить это дела раз и на всегда, акторами, где в стейт меняется всегда из одного треда.

а какой стейт кроме сессии?

Ну вот есть стейт приложения, который пользовательский. Там для него по сути написан тот же кланговский актор: очередь и tell. Потом есть всяки хэштаблицы в которых лежат эвенты, делэи, колбэки. Потом есть всякие счетчики скрытые. Флажки разные.

не достаточно будет?

Моникс я не хочу тащить в зависимости еще больше чем акку.

почему "еще больше"?

@fomkin у тебя ж по идее весь запрос должен обрабатываться одним тредом, откуда конкуренция?

почему "еще больше"?

потому что там помимо моникса теперь и кошки прилетают

@fomkin у тебя ж по идее весь запрос должен обрабатываться одним тредом, откуда конкуренция?

Нет, потому что в футуры, которые onComplete выполняют в executionContext. Это кстати еще одно проблема потому что Королев тестировался на футурах, но не привязан к ним. Очень может быть что при использовании мониксовского такска все станет колом. Акторы ведут себя просто и предсказуемо и отличии от любого самодельного зоопарка на примитавах.

Моникс я не хочу тащить в зависимости еще больше чем акку.

вообще кстати у него крутые примитивы для конкаренси

получается неблокируемый апи н тасках

ну если таски из апи торчать будут, то это такое себе

торчат. а что с этим не так?

Нет, потому что в футуры, которые onComplete выполняют в executionContext. Это кстати еще одно проблема потому что Королев тестировался на футурах, но не привязан к ним. Очень может быть что при использовании мониксовского такска все станет колом. Акторы ведут себя просто и предсказуемо и отличии от любого самодельного зоопарка на примитавах.

с чего ты взял? принцип то такой ж)

очередь и воркеры

@fomkin я для чего on complete юзается?

очередь и воркеры

Обобщаем, получаем акторы. Возвращаемся к изначальному повросу: Кланговские акторы и моя модфикация с типизацией. Плюсы, минусы, подводные камни?

@fomkin у тебя реквест разбивается на мелкие части и получается несколько футуров?

@fomkin у тебя реквест разбивается на мелкие части и получается несколько футуров?

Есть сообщения в одну сторону и есть в другую. Иногда это принимает форму реквестов, когда сендер "ждет" что ему пришлют ответ. На пример когда дергаешь поля из формы. Но в целом это асинхронная по своей сути система.

вот когда сендер ждет, эт имхо не круто

@fomkin видимых минусов нет - если тебе достаточно обертки читалки очереди - бери)

вот когда сендер ждет, эт имхо не круто

"Ждет" это значит о сохранил в мапе промис по айдишнику запроса. Есть сообщения с той стороны которые несут ответ помеченный айдишником сообщения.

хотя в случае ошибок - что делать?)

кароч фомкин, бери disruptor и мути паип на нем

ERROR: S client not available

)

1 writer - 1 reader )

кароч фомкин, бери disruptor и мути паип на нем

Не подойдет.

аа, ты ж scalajs хочешь?

Есть норм паттерн для редкообновляемых справочников в акторсистемах ?

хотя в случае ошибок - что делать?)

Да, обработки исключений нет. Отмечу. Спасибо

аа, ты ж scalajs хочешь?

Нет

тогда в чем проблема?

тогда в чем проблема?

В том что там развесистый стейт и не пайп совсем. Я не знаю кстати что за дисраптор.

зря не знаешь)

что значит не пайп?

мне трудно сервер без пайпа представить

Одно сообщение меняет стейт в разным местах.

проблема в том, что может придти несколько сообщений и это превращается в канкарент модификеишин дерева?

Обобщаем, получаем акторы. Возвращаемся к изначальному повросу: Кланговские акторы и моя модфикация с типизацией. Плюсы, минусы, подводные камни?

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

А если я хочу в кошках автоматический вывод Eq для Product (case class), мне нужно использовать какой-нибудь https://github.com/milessabin/kittens или есть встроенные способы?

короче не хранить данные в объекте, который сам по себе уже адрес сэтих данных

@fomkin почитай лс

@fomkin почитай лс

Ага, спасиб, почитаю

Тоже пойду почитаю лс

давайте все читать лс фомкина (взлом ТГ без смс)

А если я хочу в кошках автоматический вывод Eq для Product (case class), мне нужно использовать какой-нибудь https://github.com/milessabin/kittens или есть встроенные способы?

Ну естественно, все инстансы, который есть в kittens можно получить легко автоматически. Просто Сабин решил продемонстрировать, как можно усложнить решение, используя шейплесс

Мм, сарказм тут ни к чему

Могло например быть так что он сделал киттенз, а потом кошки к себе это занесли

или еще с десяток других вариантов

Могло например быть так что он сделал киттенз, а потом кошки к себе это занесли

Для кейзклассов ничего на автомате не выводится, кошки не заносят себе автовывот на шейплесс

Напрашивается автовывод: нет, нельзя

автовывод :D

Для кейзклассов ничего на автомате не выводится, кошки не заносят себе автовывот на шейплесс

это ^ и есть ответ на мой вопрос. Спасибо!

Самое автоматическое - это Eq.fromUniversalEquals

он будет .equals внутри запускать, который для кейзклассов написан

о, а вот это круто, спасибо еще раз :)