DF
Но зачем имя рекорда нужно в рантайме-то?
Size: a a a
2020 September 01
ŹR
Но зачем имя рекорда нужно в рантайме-то?
Для runtime полиморфизма
ŹR
Коим является protocol
DF
Ты можешь заматчиться на имя рекорда и без того.
DF
Или я не понимаю о чем речь.
ŹR
Да, ты можешь, но оно должно быть)
DF
foo(#bar{}) -> ok;
foo(_) -> not_ok.PG
У рекордов же нет поля с именем рекорда
Окстись
DF
Он о том, что в рантайме ты не можешь его получить без странных телодвижений вроде element(1).
PG
def record_name(r), do: :erlang.element(1, r)PG
бам, теперь есть
PG
AM
какие у вас криповые стрикеры, судари
DF
Кот с глазами Бушеми великолепен.
AL
AB
Он о том, что в рантайме ты не можешь его получить без странных телодвижений вроде element(1).
Для диспатча протокола этого и размера тапла более чем достаточно, а в момент сборки диспатча вся эта инфа уже доступна.
AB
> three main ones were Ruby, Erlang, and Clojure. Not only did we get features from those languages, but we also got part of their philosophy.
> With Clojure, there are a bunch of similar ways we approach problems, like protocols.
по итогам можно заметить, что недостаточно Валим понимает философии кложи
> With Clojure, there are a bunch of similar ways we approach problems, like protocols.
по итогам можно заметить, что недостаточно Валим понимает философии кложи
V
Всем привет!
Возник довольно общий вопрос по принципам организации erlang/elixir приложения.
Как правильно организовать параллельный доступ к данным или состоянию? Например, ets или другая хеш таблица, какая-то сущность, доступная для чтения и записи, должна конкурентно читаться несколькими потоками.
Первой идеей было использовать GenServer, в его state хранить данные и отвечать через handle. Тогда весь доступ сериализуется, нет параллельности. Можно сразу после получения запроса отдавать управление из handle с noreply и запускать процесс, который дошлет ответ клиенту, но в таком случае не понятно как синхронизироваться.
В классической модели с потоками решением был бы RWLock, который давал бы одновременное чтение и синхронизировал записи.
Как такую задачу решить в акторной модели?
Интересуют как конкртеные ответы как это сделать опрделенными средствами, напримр, на ets (тут кажется можно пропробовать просто доступаться к таблице по глобальному идентификатору, хотя опять же без синхронизации) . Так и более общие, какие-то паттерны. Причем также интересна специфика в отдельных случаях, например когда есть только чтение, чтение и запись read/write-heavy и т.п.
Возник довольно общий вопрос по принципам организации erlang/elixir приложения.
Как правильно организовать параллельный доступ к данным или состоянию? Например, ets или другая хеш таблица, какая-то сущность, доступная для чтения и записи, должна конкурентно читаться несколькими потоками.
Первой идеей было использовать GenServer, в его state хранить данные и отвечать через handle. Тогда весь доступ сериализуется, нет параллельности. Можно сразу после получения запроса отдавать управление из handle с noreply и запускать процесс, который дошлет ответ клиенту, но в таком случае не понятно как синхронизироваться.
В классической модели с потоками решением был бы RWLock, который давал бы одновременное чтение и синхронизировал записи.
Как такую задачу решить в акторной модели?
Интересуют как конкртеные ответы как это сделать опрделенными средствами, напримр, на ets (тут кажется можно пропробовать просто доступаться к таблице по глобальному идентификатору, хотя опять же без синхронизации) . Так и более общие, какие-то паттерны. Причем также интересна специфика в отдельных случаях, например когда есть только чтение, чтение и запись read/write-heavy и т.п.
AB
Всем привет!
Возник довольно общий вопрос по принципам организации erlang/elixir приложения.
Как правильно организовать параллельный доступ к данным или состоянию? Например, ets или другая хеш таблица, какая-то сущность, доступная для чтения и записи, должна конкурентно читаться несколькими потоками.
Первой идеей было использовать GenServer, в его state хранить данные и отвечать через handle. Тогда весь доступ сериализуется, нет параллельности. Можно сразу после получения запроса отдавать управление из handle с noreply и запускать процесс, который дошлет ответ клиенту, но в таком случае не понятно как синхронизироваться.
В классической модели с потоками решением был бы RWLock, который давал бы одновременное чтение и синхронизировал записи.
Как такую задачу решить в акторной модели?
Интересуют как конкртеные ответы как это сделать опрделенными средствами, напримр, на ets (тут кажется можно пропробовать просто доступаться к таблице по глобальному идентификатору, хотя опять же без синхронизации) . Так и более общие, какие-то паттерны. Причем также интересна специфика в отдельных случаях, например когда есть только чтение, чтение и запись read/write-heavy и т.п.
Возник довольно общий вопрос по принципам организации erlang/elixir приложения.
Как правильно организовать параллельный доступ к данным или состоянию? Например, ets или другая хеш таблица, какая-то сущность, доступная для чтения и записи, должна конкурентно читаться несколькими потоками.
Первой идеей было использовать GenServer, в его state хранить данные и отвечать через handle. Тогда весь доступ сериализуется, нет параллельности. Можно сразу после получения запроса отдавать управление из handle с noreply и запускать процесс, который дошлет ответ клиенту, но в таком случае не понятно как синхронизироваться.
В классической модели с потоками решением был бы RWLock, который давал бы одновременное чтение и синхронизировал записи.
Как такую задачу решить в акторной модели?
Интересуют как конкртеные ответы как это сделать опрделенными средствами, напримр, на ets (тут кажется можно пропробовать просто доступаться к таблице по глобальному идентификатору, хотя опять же без синхронизации) . Так и более общие, какие-то паттерны. Причем также интересна специфика в отдельных случаях, например когда есть только чтение, чтение и запись read/write-heavy и т.п.
главный и единственный shared state в beam - это ets. как результат - ets обязательно нужно уметь использовать и понимать