Pull to refresh

Comments 17

Расскажи, что в erlyvideo можно заменить на gproc
Регистратор процессов — очень популярный паттерн в erlang-приложениях. Довольно часто он реализуется по нескольку раз в одном и том же приложении, я сам с десяток этих регистраторов написал, различались они совсем немного.
В erlyvideo на gproc можно заменить, думаю, регистрацию процессов ems_media_clients, затем признаки регистратора есть в media_provider, и в SIP в нескольких местах.
смотри, очень важная тема — получить список процессов и их регистрацию напрямую из ets таблицы.
gproc лезет через сервер к содержимому таблицы или как?
Через gproc:select/1,2,3 можно делать запросы напрямую в ets.
Спасибо за статью, пишите такие ещё!
С API приложения можно ознакомиться на странице github.com/esl/gproc/blob/master/doc/gproc.md.
Локальная регистрация

в ссылке лишняя точка
Спасибо, поправил
А пул подключений, например, к БД есть смысл в gproc хранить?
Я в этом не вижу смысла. Храню идентификаторы процессов-коннектов в списке и дёргаю их round-robin'ом.
Я возможно не совсем понял, но зачем в принципе давать имена процессам, которые не являются долгоживущими? Можете пояснить на каком-нибудь примере?
К процессам же надо как-то обращаться, значит, нужно ассоциировать их идентификатор с каким-то значащим термом. Например, надо отправить сообщение процессу, который представляет на серверной стороне пользователя «vasya». Тогда мы делаем примерно так: gproc:lookup_local_name({user, «vasya»})! {some, message}.

Прошу прощения за то, что сразу не ответил, почему-то перестали приходить письма о появлении комментариев.
Опять же, я не настолько искушен в этом деле. Наверно просто я сам не встречался с такими задачами. Но в моих задачах есть либо именованные процессы, к которым надо обращаться по имени, либо воркеры, к которым обращение идет через pid либо они первые начинают) Но все равно спасибо, будем знать, что к чему и если возникнет необходимость — использовать.
Да, как раз воркеры. Вот вы этот pid для обращения к воркерам откуда получаете? Почему именно этому конкретному pid-у должно уйти сообщение, а не другому?
Ну в частности в моем проекте воркеры между собой не общаются. Они общаются либо с именованными процессами, либо с супервайзером. Поэтому я слегка и не понял задумки.

Вообще у меня возникла такая идея — прикрутить эту диспетчиризацию к супервайзеру. Он знает, какие у него дети присутствуют и в качестве идентификатора может быть любой терм. Просто подсознательно идея с глобальным состоянием меня пугает. Единственное — я не вижу в доке способ получения спеки одного дочернего процесса, только which_children. Но думаю, что это можно обойти.

Что вы думаете по поводу этой идеи?
Из списка, возвращаемого функцией which_children, можно выбирать нужный идентификатор с помощью обычных списковых операций.

Недостаток такого подхода в том, что удаление спецификации при завершении процесса происходит не атомарно, и могут возникнуть всяческие гонки. К тому же, хранение этих ассоциаций (SomeId <-> pid) в ets позволяет делать удобные запросы с помощью MatchSpec, а gproc как раз так и делает. Помимо этого, с помощью gproc можно дожидаться момента, когда процесс уже точно запущен и зарегистрирован, и производить регистрацию глобально, во всём кластере.
UFO just landed and posted this here
Sign up to leave a comment.

Articles