Вопрос чисто теоретический, вопрос синтаксиса и деталей реализации не стоит. Просто интересно узнать мнение людей, программирующих на Erlang.
Насколько была бы полезна широковещательная рассылка сообщений в Erlang?
С т.з. программиста выглядит примерно так: вначале ряд процессов (возможно ни одного) неким способом декларируют свой интерес в сообщениях некого типа; далее, когда процесс посылает сообщение этого типа, оно доставляется всем зарегистрированным процессам.
Может использоваться для нотификаций о каком-то глобальном событии, или для организации "восходящих" потоков управления, когда отсылающий процесс не завязан ни на кол-во, ни на состав, ни на наличие вообще получателей сообщения.
Здравствуйте, remark, Вы писали:
R>Вопрос чисто теоретический, вопрос синтаксиса и деталей реализации не стоит. Просто интересно узнать мнение людей, программирующих на Erlang.
R>Насколько была бы полезна широковещательная рассылка сообщений в Erlang?
Джо вроде всё собирался добавить оператор "bang-bang" вида !! , который бы как раз и посылал сообщение нескольким процессам. Подробности уже толком не помню (наверняка в мейллисте обсуждение было не раз, можешь поискать)
R>С т.з. программиста выглядит примерно так: вначале ряд процессов (возможно ни одного) неким способом декларируют свой интерес в сообщениях некого типа; далее, когда процесс посылает сообщение этого типа, оно доставляется всем зарегистрированным процессам. R>Может использоваться для нотификаций о каком-то глобальном событии, или для организации "восходящих" потоков управления, когда отсылающий процесс не завязан ни на кол-во, ни на состав, ни на наличие вообще получателей сообщения.
Чтот у тебя уже слишком нетривиальна логика вырисовывается...
И всё это должно выражаться в одной конструкции языка?
Лично я особого смысла в отсылке сообщения "сразу всем" не вижу, можно сделать к примеру A!B!C!{my_message}, или по списку пройтись с foreach.
В любом случае в Эрланге вроде никогда не было синхронизации доставки сообщений между разными процессами, есть лишь гарантия на очерёдность получения событий одним мейлбоксом.
Здравствуйте, remark, Вы писали:
R>Вопрос чисто теоретический, вопрос синтаксиса и деталей реализации не стоит. Просто интересно узнать мнение людей, программирующих на Erlang.
R>Насколько была бы полезна широковещательная рассылка сообщений в Erlang?
R>С т.з. программиста выглядит примерно так: вначале ряд процессов (возможно ни одного) неким способом декларируют свой интерес в сообщениях некого типа; далее, когда процесс посылает сообщение этого типа, оно доставляется всем зарегистрированным процессам. R>Может использоваться для нотификаций о каком-то глобальном событии, или для организации "восходящих" потоков управления, когда отсылающий процесс не завязан ни на кол-во, ни на состав, ни на наличие вообще получателей сообщения.
Очень похоже на вариант событийно-подписной схемы которая часто используется при работе с Erlang.
Правда обычно это один процесс event_manager и несколько обработчиков (event_handler) — модулей реализующих поведение gen_event.
Обработчики имеют состояние и при возникновении нового события дергаются менеджером.
Собственно можно реализовать обработчик, который будет рассылать эти события в виде сообщений процессам.
Вобщем непонятно зачем тут изменения синтаксиса и т.п.
R>
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, remark, Вы писали:
R>>Вопрос чисто теоретический, вопрос синтаксиса и деталей реализации не стоит. Просто интересно узнать мнение людей, программирующих на Erlang.
R>>Насколько была бы полезна широковещательная рассылка сообщений в Erlang?
К>Джо вроде всё собирался добавить оператор "bang-bang" вида !! , который бы как раз и посылал сообщение нескольким процессам. Подробности уже толком не помню (наверняка в мейллисте обсуждение было не раз, можешь поискать)
Вот оно.
Но идея несколько другая — все есть процесс и банг банг единый синтаксис доступа ко всему
Здравствуйте, Mikl Kurkov, Вы писали:
MK>Здравствуйте, Курилка, Вы писали:
К>>Джо вроде всё собирался добавить оператор "bang-bang" вида !! , который бы как раз и посылал сообщение нескольким процессам. Подробности уже толком не помню (наверняка в мейллисте обсуждение было не раз, можешь поискать)
MK>Вот оно. MK>Но идея несколько другая — все есть процесс и банг банг единый синтаксис доступа ко всему
Странно, как это я эту доку пропустил...
Но если так, то мне не особо нравится такая идея универсального оператора
Прикольно-то оно прикольно, но на практике чую даст лишь гемор (сиди разбирайся, что там в строку запихано было)
Здравствуйте, Курилка, Вы писали:
К>Чтот у тебя уже слишком нетривиальна логика вырисовывается...
К>И всё это должно выражаться в одной конструкции языка?
Сколькими угодно. Можно вообще в библиотеке.
К>Лично я особого смысла в отсылке сообщения "сразу всем" не вижу, можно сделать к примеру A!B!C!{my_message}, или по списку пройтись с foreach.
Ну пройтись по списку — это, насколько я понимаю, как раз и есть то, о чём я говорю. Так это полезно? Это используется?
К>В любом случае в Эрланге вроде никогда не было синхронизации доставки сообщений между разными процессами, есть лишь гарантия на очерёдность получения событий одним мейлбоксом.
А гарантия на очерёдность получения событий несколькими мейлбоксами — это как?
Здравствуйте, Mikl Kurkov, Вы писали:
MK>Очень похоже на вариант событийно-подписной схемы которая часто используется при работе с Erlang.
А, вот это я и хотел услышать. Т.е. такая схема используется достаточно часто, но реализуется руками. Т.е. создаём список всех заинтересованных процессов, а потом проходим по нему и рассылаем.
Или не руками, а есть какие-то стандартные компоненты и интерфейсы?
MK>Правда обычно это один процесс event_manager и несколько обработчиков (event_handler) — модулей реализующих поведение gen_event. MK>Обработчики имеют состояние и при возникновении нового события дергаются менеджером.
Вот это не очень понял... Т.е. такая схема используется внутри одного процесса, а не между процессами?
MK>Вобщем непонятно зачем тут изменения синтаксиса и т.п.
Да, не, синтаксис менять не обязательно. Интересно было как Erlang обходится без широковещательной рассылки. Языком она не поддерживается. А вещь полезная. А про то, что реализуется руками был не в курсе.
Вообще странно для системы, основанной на обмене сообщениями, предоставить только один примитив — отсылка конкретному процессу...
R>> MK>
remark wrote:
> А про то, что реализуется руками был не в курсе. Вообще > странно для системы, основанной на обмене сообщениями, предоставить только > один примитив — отсылка конкретному процессу...
ну так эти процессы можно собрать в список и им отсылать
имхо вполне кошерно. особенно если предположить что с erlang-ом может
общаться кто-то еще. если клиент не хочет/не может получать неинтересные
ему сообщения, буфер под это дело запросто переполнится.
при таком подходе подписка на интересные вещи -- самое оно.
у меня правда пока не erlang, а ocaml и C (smnp), но остановился я именно на
таком варианте (хотя да, началось все с широковещательных пакетов...)
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Mikl Kurkov, Вы писали:
MK>>Очень похоже на вариант событийно-подписной схемы которая часто используется при работе с Erlang.
R>А, вот это я и хотел услышать. Т.е. такая схема используется достаточно часто, но реализуется руками. Т.е. создаём список всех заинтересованных процессов, а потом проходим по нему и рассылаем. R>Или не руками, а есть какие-то стандартные компоненты и интерфейсы?
Для простых случаев есть модуль rpc с функциями для рассылки сообщений нескольким получателям, в том числе на разных нодах.
А так и руками как правило не так уж и много написать нужно.
MK>>Правда обычно это один процесс event_manager и несколько обработчиков (event_handler) — модулей реализующих поведение gen_event. MK>>Обработчики имеют состояние и при возникновении нового события дергаются менеджером.
R>Вот это не очень понял... Т.е. такая схема используется внутри одного процесса, а не между процессами?
Ну не всегда нужно работать с процессами. Часто это применяется для логгирования например, тут достаточно обычную функцию вызвать.
Менеджеры есть нескольких видов (например alarm_handler — предоставляет возможность реагировать на изменение состояния каких-то параметров — вкл\выкл), можно свой написать. Функциям обработчика передается состояние в котором например вполне может храниться идентификатор процесса которому посылается например
определенное сообщение о наступлении события.
MK>>Вобщем непонятно зачем тут изменения синтаксиса и т.п.
R>Да, не, синтаксис менять не обязательно. Интересно было как Erlang обходится без широковещательной рассылки. Языком она не поддерживается. А вещь полезная. А про то, что реализуется руками был не в курсе. R>Вообще странно для системы, основанной на обмене сообщениями, предоставить только один примитив — отсылка конкретному процессу...
Ну на то он и примитив — простейшая и наиболее универсальная операция. Посылка асинхронного сообщения одному процессу. А уже с ее помощью можно более сложные поведения реализовать.
Синхронную посылку например или широковещательную. Тут все правильно как раз, на мой взгляд.
R>>> MK>> R>
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Курилка, Вы писали:
К>>Лично я особого смысла в отсылке сообщения "сразу всем" не вижу, можно сделать к примеру A!B!C!{my_message}, или по списку пройтись с foreach.
R>Ну пройтись по списку — это, насколько я понимаю, как раз и есть то, о чём я говорю. Так это полезно? Это используется?
Ну если такой функционал нужен, то он используется
По списку это может выглядеть примерно так:
К>>В любом случае в Эрланге вроде никогда не было синхронизации доставки сообщений между разными процессами, есть лишь гарантия на очерёдность получения событий одним мейлбоксом.
R>А гарантия на очерёдность получения событий несколькими мейлбоксами — это как?
Я имел в виду временную синхронизацию между разными мейлбоксами (очередями сообещений процессов). Скажем послал ты процессам П1 и П2(обоим сразу), события С1 и С2 именно в таком порядке. Никто не будет гарантировать, что в П1 событие С2 придёт позже чем в П2 придёт событие С1.
Здравствуйте, Mamut, Вы писали:
_>>ну так эти процессы можно собрать в список и им отсылать _>>имхо вполне кошерно.
M>для меня как-то стало откровением, что Pid ! Message также возвращает значение, поэтому можно так (не знаю, правда, зачем ) M>
Здравствуйте, remark, Вы писали:
К>>Чтот у тебя уже слишком нетривиальна логика вырисовывается...
К>>И всё это должно выражаться в одной конструкции языка?
R>Сколькими угодно. Можно вообще в библиотеке.
В библиотеке это уже есть, пользуйтесь на здоровье. Модуль pg2.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Mamut, Вы писали:
_>>>ну так эти процессы можно собрать в список и им отсылать _>>>имхо вполне кошерно.
M>>для меня как-то стало откровением, что Pid ! Message также возвращает значение, поэтому можно так (не знаю, правда, зачем ) M>>
M>>[ Pid ! Message || Pid <- ProcessList ]
M>>
К>С целью доп. нагрузки на GC?
1) Так можно независимо от того, возвращает он значение или нет.
2) Дополнительной нагрузки на GC это не создает начиная с R12. Если результат comprehensions не возвращает значения — то список не конструируется, считается что это просто цыкл, выполняющийся заради побочного значения. Да, Эрланг начал обростать неочевидными оптимизациями.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Курилка, Вы писали:
К>>Здравствуйте, Mamut, Вы писали:
M>>>для меня как-то стало откровением, что Pid ! Message также возвращает значение, поэтому можно так (не знаю, правда, зачем ) M>>>
M>>>[ Pid ! Message || Pid <- ProcessList ]
M>>>
К>>С целью доп. нагрузки на GC?
G>1) Так можно независимо от того, возвращает он значение или нет.
А разве кто-то говорил про "нельзя"? G>2) Дополнительной нагрузки на GC это не создает начиная с R12. Если результат comprehensions не возвращает значения — то список не конструируется, считается что это просто цыкл, выполняющийся заради побочного значения. Да, Эрланг начал обростать неочевидными оптимизациями.
Надо будет-таки поразбираться поподробней с R12
Имхо не очень хорошее это дело — неочевидные оптимизации, т.к. фактически программист приучается к тому, что можно и не думать особо о том, что же он написал (всё равно ведь работает).
Я бы лично настаивал в приведённом случае на явном вызове lists::foreach/2.
Здравствуйте, Курилка, Вы писали:
К>>>В любом случае в Эрланге вроде никогда не было синхронизации доставки сообщений между разными процессами, есть лишь гарантия на очерёдность получения событий одним мейлбоксом.
R>>А гарантия на очерёдность получения событий несколькими мейлбоксами — это как?
К>Я имел в виду временную синхронизацию между разными мейлбоксами (очередями сообещений процессов). Скажем послал ты процессам П1 и П2(обоим сразу), события С1 и С2 именно в таком порядке. Никто не будет гарантировать, что в П1 событие С2 придёт позже чем в П2 придёт событие С1.
Для разных процессов понятие порядка не релевантно. Это Теория Относительности — разные точки пространства -> разное время -> понятия порядка "раньше"/"позже" не существует.
Понятие порядка в данном случае можно определить только через причинно-следственные связи, т.е. если П1 и П2 потом тоже будут обмениваться сообщениями, т.н. casual fifo порядок против per-producer fifo порядка. Но тут, я думаю, в Erlang должно быть все нормально, т.е. casual fifo порядок должен гарантироваться языком.
