Erlang. Что это, зачем, как и для кого.
Статья короткая, если понравиться, попробую осветить этот язык программирования подробнее.
Что
Erlang, это функциональный язык программирования с динамической типизацией, главной особенностью которого является программирование на уровне отдельных процессов(почти аналог threads в других ЯП), коммуникация между которыми реализуется с помощью MPI(Message Passing Interface).
Зачем
Рост частот центральных процессоров остановился. Растет количество ядер и количество узлов в кластерах. Erlang создан для максимального упрощения разработки программ которые могут использовать всю мощь многоядерных и/или много узловых систем.
Успешные примеры использования Erlanga — Jabber(ура!) сервер ejabberd, web-сервер YAWS и многочисленные эксперименты, например comet-программа(специфический стиль программирования веб-сайтов, когда сервер не разрывает подключения с клиентом, а продолжает пересылать ему данные при необходимости) способная держать 1,000,000(миллион) TCP-подключений.
Erlang Programming Language — Computerphile
Никаких сравнений я приводить не буду, достаточно сказать, что ети программы выдерживают бешеную нагрузку и очень сопротивляются попыткам их убить 🙂
Как
Программирование на уровне отдельных, изолированных процессов дает много преимуществ перед обычным стилем программирования параллельного ПО.
Начнем из истоков — почему трудно программировать такое ПО на жаве, си или шарпе? Проблема очень глобальная и существует во всех этих языках — общий доступ к памяти. Программируя на этих ЯП вы не можете быть уверены, что вместимое памяти, куда ссылаются ваши переменные не изменил какой-то другой поток(трэд, thread, нить. ). Из-за этого, очень часто приходиться прибегать к разнообразным, проверенным временем, трюкам — локи, мутексы, семафоры. И делать это трудно. Трудно не только начинающему программисту, но и программисту с опытом, от которого зависит работоспособность системы, если над ней работают еще несколько опытных/неопытных программистов.
Вообще говоря, в Erlang’е ета проблема не решена. Она просто изолирована на уровень ниже самого языка. Каждый процесс изолирован и не имеет доступа к памяти других процессов.
В двух словах: если нет общей памяти то нет проблемы с доступом к этой памяти.
Для кого
Erlang очень прост в изучении, в синтаксисе можно разобраться в течении дня-двух, в принципах программирования — неделя-другая. Но вот парадигма программирования достаточно сложна и переключиться на нее(особенно если есть огромный опыт в императивных ЯП) достаточно сложно и иногда совсем не хочется. Не раз слышал — как можно программировать не объектами? Весь мир состоит из объектов и взаимодействия между объектами! Ответ банальный — весь мир состоит из процессов и взаимодействия между процессами в той же мере в какой он состоит из объектов.
С использованием этого ЯП многие задачи решаються тривиально, и я считаю, что Erlang — лучший ЯП, с которого стоит начинать знакомство с функциональными языками. Особенно если программы должны быть параллелизированы и кластеризированы.
Erlang and 5 Things you Need to Know About it in 2021 | Erlang Programming | Erlang pros and cons
Источник: habr.com
Erlang otp что это за программа
Полный спектр компьютерных услуг!
Загрузка. Пожалуйста, подождите.
Сообщение сайта
(Сообщение закроется через 2 секунды)
Внимание!
Erlang/OTP / Слежение за процессами и обработка ошибок, часть 1
Decker
Просмотр профиля
28.2.2011, 14:25
Группа: Главные администраторы
Сообщений: 14349
Регистрация: 12.10.2007
Из: Twilight Zone
Пользователь №: 1
0 Преамбула
Согласитесь приятно, когда в хозяйстве все под контролем и все в порядке, каждая вещь стоит на своем месте и четко выполняет свое вселенское предназначение. Сегодня мы рассмотрим вопросы организации порядка в огромном множестве процессов эрланга. Базовые понятия о процессах эрланга можно прочитать в этом посте.
1 Ты следишь за мной – я слежу за тобой
Все, кто так или иначе знакомился с эрлангом, слышал фразу: «Пусть процесс упадет, а другой что-нибудь сделает с этим или разберется с проблемой». Согласитесь, когда что-то ломается – это плохо, а если мы ещё об этом и длительное время не знаем, то это плохо вдвойне. Сломала ваша кошка свою миску с молоком и сокрыла этот ужасный факт от вас – плохо!
Пусть миска следит за кошкой, а кошка за миской. Да простят читатели автора за такое грубое сравнение. Итак, перейдем к делу.
Связь процессов между собой для слежения за состоянием друг друга – это одна из базовых концепций эрланга. В сложной и хорошо спроектированной системе ни один процесс не должен «висеть в воздухе». Все процессы должны быть встроены в дерево контроля, листьями которого являются рабочие процессы, а внутренние узлы следят за рабочими (контроллеры) [2 |см. принципы OTP (Open Telecom Platform)]. Хотя можно сделать, чтобы и два рабочих были связаны.
Если не подниматься на уровень абстракции, который предоставляет OTP, в эрланге есть два механизма связи процессов:
- Связь (link) – двунаправленная связь между двумя процессами.
- Мониторы – однонаправленная связь процесса-наблюдателя и наблюдаемого.
Для создания связей между процессами используются следующие функции:
- erlang:link/1 – создание связи между вызывающим функцию и другим процессом;
- erlang:spawn_link/1/2/3/4 (есть так же псевдоним proc_lib:spawn_link/1/2/3/4) – создание нового процесса и прилинковка его к процессу, вызывающему функцию;
- erlang:unlink/1 – удаление связи между процессом, вызывающим функцию, и указанным в аргументах;
- pool:pspawn_link/3 – создание нового процесса на одном из узлов в пуле и прилинковка его к процессу, вызывающему функцию.
Что дает нам двунаправленная связь между процессами? Связи определяют путь распространения ошибок. Один процесс умер, второй об этом узнал и в ряде случаев, которые мы рассмотрим ниже, он тоже завершит свою работу, разослав сигнал всем остальным процессам, которые к нему так же привязаны. Данный механизм позволяет дистанционно обрабатывать ошибки, т.е. обработчиком может быть отдельный процесс (контроллер), к которому все эти ошибки будут «стекаться» по связям, причем процесс-обработчик может находиться вообще на другом узле. И все эти вкусности почти бесплатно – все уже реализовано в платформе, нам лишь остается правильно построить нашу мега-супер-отказо-распределенную систему.
Когда процесс падает (см. рисунок 2) отправляется сигнал выхода всем прилинкованным процессам, данный сигнал содержит информацию, какой процесс и по какой причине погиб в бою. Сигнал представляет собой кортеж .
Существует два предопределенных значения переменной Reason:
- normal – данное значение причины устанавливается, если процесс выполнил всю работу, которой мы его нагрузили, т.е. попросту достиг конца функции, с которой он был вызван. В этом случае процессы, которые слинкованы с ним, не завершат свою работу.
- kill – не перехватываемый сигнал, который всегда убивает процесс, даже системный, используется для принудительного завершения сбойных процессов.
Для того чтобы процесс мог перехватывать сигналы выхода, его необходимо сделать системным поставив флаг trap_exit с помощью вызова функции process_flag(trap_exit, true).
Итак, хватит теории, давайте все попробуем на практике. Открываем наш любимый редактор и создаем небольшой модуль. Давайте сначала протестируем нормальное завершение процесса. Для простоты эксперимента в качестве одного из процессов у нас будет shell.
start_n(Sysproc) ->
%% test normal reason
process_flag(trap_exit, Sysproc),
io:format(«Shell Pid: ~p~n», [self()]),
Pid = spawn_link(links_test, loop_n, [self()]),
io:format(«Process started with Pid: ~p~n», [Pid]).
loop_n(Shell) ->
%% loop for test normal reason
receive
after 5000 ->
Shell ! timeout
end.
В модуле определено две функции: первая start_n создает новый процесс и линкует его с вызывающим процессом (в нашем случае это будет shell), в качестве параметра принимает значение boolean, которое делает процесс системным. Вторая loop_n – это тело создаваемого процесса, в качестве аргумента мы передаем ему Pid вызывающего процесса (shell). Через 5 секунд после запуска процесса он отправляет шелу сообщение timeout. Компилируем и запускаем наш процесс.
Вызываем функцию links_test:start_n с параметром false, т.е. shell не системный процесс и сигналы выхода ловить не может. Видим, что процесс был успешно создан, т.к. в функции loop_n нет хвостовой рекурсии, она успешно отработает и процесс завершится. Вызываем функцию flush(), чтобы сбросить все сообщения из ящика shell, и видим, что было получено сообщение от нашего процесса «Shell got timeout». Никаких сигналов выхода мы не видим, так как флаг обработки данного вида сигналов не был установлен. Теперь сделаем shell системным процессом.
После выполнения функции видим, что помимо сообщения timeout было получено сообщение о нормальном завершении от нашего процесса ,normal>. Замечательный механизм, позволяет нам сэкономить на количестве кода, когда необходимо узнать, что процесс выполнил свою работу (не надо самим отправлять сигнал «Я все сделал»).
Теперь давайте попробуем сгенерировать ошибку, отличную от normal. Модифицируйте код модуля как в листинге ниже.
start_n(Sysproc) ->
%% test abnormal reason
process_flag(trap_exit, Sysproc),
io:format(«Shell Pid: ~p~n», [self()]),
Pid = spawn_link(links_test, loop_n, [self()]),
io:format(«Process started with Pid: ~p~n», [Pid]).
loop_n(Shell) ->
%% loop for test abnormal reason
receive
after 5000 ->
Shell ! timeout,
1 / 0
end.
Мы очень суровы и решили сделать деление на ноль, компилятор естественно нас предупредит, что мы не правы, но мы его предупреждение просто проигнорируем.
Обратите внимание Shell Pid = . Через 5 секунд вываливается ошибка, объясняющая, что все-таки мы были не правы. Попробуем посмотреть, что же в очереди у shell, а там пусто. Где же наше письмо timeout? Выполним команду self(), Shell Pid теперь равен — это значит, что наш сбойный процесс послал сигнал выхода shell с причиной ]>, а так как shell в данном примере не системный процесс, он благополучно упал и был перезапущен каким-то контроллером (каким мы возможно рассмотрим в следующих статьях). Теперь включим флаг обработки сигналов выхода.
Думаю, комментарии к результатам излишни, тут все понятно.
Мы разобрали четыре случая:
Сигнал trap_exit
Причина завершения процесса
Действие процесса, который остался «жив»
true
normal
В почтовый ящик приходит сообщение
false
normal
Процесс продолжает свою работу
true
Любая отличная от normal и kill
В почтовый ящик приходит сообщение
false
Любая отличная от normal и kill
Процесс умирает, рассылая сигнал выхода по всем своим связям (т.е. происходит распространение ошибки)
В следующей статье мы рассмотрим механизм мониторов и постреляем по процессам сигналами kill. Хотелось бы услышать мнение хаброжителей, статьи по каким темам эрланга вам будут наиболее интересны?
Список литературы
3. ERLANG Programming by Francesco Cesarini and Simon Thompson.
4. Programming Erlang: Software for a Concurrent World by Joe Armstrong.
Original source: habrahabr.ru (comments).
Источник: dml.compkaluga.ru
Erlang otp что это за программа
МЕРОПРИЯТИЯ
QAtalks: Tools https://proglib.io/p/language-go» target=»_blank»]proglib.io[/mask_link]
Erlang otp что это за программа
Иван Осокин
Оцените автора
Добавить комментарий Отменить ответ
Свежие записи
- Особенности применения профильных фальш-ручек GRANDIS
- Зачем нужны промокоды?
- Особенности работы выдувного экструдера
- Аренда кабриолетов
- Контейнерные перевозки грузов из Китая: главные преимущества и недостатки
Вам также может понравиться
Перед покупкой 1 комнатной квартиры в Салавате https://gurava.ru/geocities/21/%D0%A1%D0%B0%D0%BB%D0%B0%D0%B2%D0%B0%D1%82?property_type=1https://siding-rdm.ru/kod-oshibki-001-v-otp-banke-chto-eto-takoe/» target=»_blank»]siding-rdm.ru[/mask_link]