Здравствуйте, SkyDance, Вы писали:
N>>И таки да. Принято в 28.0.
SD>Знаю, я ж с Rockard'ом это и начал. Но в то время не было понимания, как сделать это непротиворечивым способом. Сейчас понимание есть, и конкретное применение тоже, и полная обратная совместимость через process options. Ты обрати внимание, там реально интересный подход! С сохранением всех существующих гарантий очередности доставки сообщений. Весьма элегантный способ, который 6 лет назад мне просто не пришел в голову (а должен был, ведь именно тогда process aliases появились, пусть и для других целей).
Ёпрст... ты серьёзно???
Представим себе расширенный send(), в котором указывается номер очереди. В процессе — N очередей списками, для каждой строго FIFO порядок. Умолчательная очередь для совместимости — номер 0, а, например, ответы на gen_server:send идут в очередь 7. Есть "cохранение всех существующих гарантий очередности доставки сообщений"? Да, есть. Это тупейшая тривиальщина, над которой в принципе не надо думать более пяти минут, и то которые уйдут на перекур.
Если о чём-то стоило тут вообще думать, так это о том, как доработать синтаксис, если надо выбирать только из конкретной очереди, с приоритетами, ограничением по длине, таймауту и всё такое.
Алиас процесса — чтобы не расширять межнодовый протокол? Так почему бы не расширить его?
N>>Ну, слушаю комментарии. Например, о том, что священная чистота нарушена, что надо было на все заседания приносить мумию Армстронга, чтобы это не случилось, и так далее.
SD>Процесс потому и занял много лет, что потребовалось переосмысление некоторых в начале неясных моментов. Основная идея, которой не существовало 15 лет назад — process aliases. А вовсе не банальые multiple message queue (много mailbox'ов). Традиционно, процесс сам выбирает, из какого mailbox'а читать. На современном витке спирали эволюции, скажем, тот же Go, каналы.
_Для начала_ можно было сделать и такую реализацию, по которой все очереди вначале равномерно проходятся, насколько хватает их глубины, в поисках нужного паттерна, а каждый следующий поиск начинается с очереди следующей по кругу за той, на которой закончили. Это точно так же дало бы полноценный эквивалент с равномерным выбиранием из всех очередей. После этого уже играться с синтаксисом.
SD>Реализация в Erlang кардинально отличается. Очередь сообщений все равно только одна. Получателю не нужно жонглировать множественными mailbox'ами. Вместо этого, создается process alias с приоритетной отправкой сообщений. Это решение отличается от предложенного мной изначально. В хорошую ли сторону или нет, можно спорить. Но — факт — инвариант сохраняется: между двумя процессами соблюдаются гарантии по доставке сообщений.
Повторюсь — сделать так, чтобы в пределах _одного номера очереди_ между двумя процессами соблюдались гарантии очерёдности доставки — задача для студента-первокурсника. А между разными очередями она и не предполагалась. Можно начать с одинаковых приоритетов, будет работать просто за счёт того, что недефолтные очереди короче. А потом прикручивать приоритеты, по желанию, но я бы их по умолчанию не делал абсолютными.
N>>Или же с честным признанием, что пока 15 лет тормозили с решением насущных проблем, пользовательская база сократилась в разы, все, кто мог, сбежали на другие средства, а дедам остаётся только идти ловить рыбу и заниматься другими пенсионерскими делами.
SD>"Что мертво умереть не может" (С)
SD>Пользовательская база, кстати, возросла. Я Elixir считаю диалектом Erlang'а, потому что BEAM. Даже в EEF board members, теперь половина Elixir-овски. Жаль, я больше не имею достаточно времени на поддержку этой экосистемы, да и open source в целом. Так что, завтра официально последний день в качестве board member'а EEF.
Ну абсолютные цифры меня не очень волнуют, а вот относительные — для общей группы ниш — резко упали. Но я подозреваю, что и в абсолютных не всё гладко.
SD>Про пенсионерские дела согласен, я уже тоже готов. Хочу на пенсию. Устал работать.
Мне казалось, я старше. Мне по-прежнему многое интересно, хотя половину времени, да, чертыхаюсь от "до чего же всё повторяется".
