Как именно реализованы процессы в Erlang?

#erlang #cpp

Вопрос несет сугубо академический характер.
Собственно:

Erlang is designed for massive concurrency. Erlang processes are light-weight (grow
and shrink dynamically) with small memory footprint, fast to create and terminate and
the scheduling overhead is low.

Какие условия должны соблюдаться для того, что-бы было возможно реализовать подобную
модель, какое API используется? В общем - как реализовать такого рода поведение средствами
C/C++ или других языков? В первую очередь интересует не код, а теория.
PS: Когда-то гуглил на эту тему, но, к моему большому удивлению, толкового ответа
не нашел. Более того - многие писали о том, что реализовать подобную модель средствами
С/C++ невозможно, во что мне верится с трудом.    

Ответы

Ответ 1

Будем считать, что речь идет о BEAM, потому что, вообще говоря, у Erlang была богатая
история.
Начиная с R13 (см. презентацию Ульфа Вигера, стр. 19), при условии, что BEAM собрано
с поддержкой SMP, создается несколько шедулеров (число определяется опцией +S, как
они соотносятся с логическими процессорами определяется флагом +sbt), у каждого есть
своя очередь процессов. Процесс — всего лишь структура данных, включающая в себя собственную
независимую кучу, стек (даже два, в случае с HiPE, см. стр.4) и все положенные процессу
регалии (мейлбокс, словарь процесса, тысячи всякого). Собственно, структуру struct
process можно посмотреть в исходниках BEAM, в файле erl_process.h.
И, к вопросу многозадачности — шедулер реализует вытесняющую многозадачность, раз
в определенное число редукций (по сути, операций) переключаясь на другой процесс. Какой-нибудь
драйвер, как честно предупреждает документация — «this means that all operations in
the driver must be non-blocking, and that any crash in the driver will bring the whole
emulator down» — может завесить поток или вообще уронить всю VM.
Вот, собственно, и все, вроде бы, если не лезть во всякие тонкости и детали (которых
я и сам не шибко в курсе, т.к. потроха BEAM, можно сказать, никогда толком и не трогал).

Можно ли писать одну программу на нескольких языках? [закрыт]

#java #erlang

        
             
                
                    
                        
                            Closed. This question is opinion-based. It is not currently
accepting answers.
                            
                        
                    
                
                            
                                
                
                        
                            
                        
                    
                        
                            Want to improve this question? Update the question so
it can be answered with facts and citations by editing this post.
                        
                        Closed 3 года назад.
                                                                                
           
                
        
Я начал изучать функциональное программирование. Пока в основном по книге СИКП. Видно,
что это крутая штука. Когда нет управления состоянием - ФП по-моему очень облегчает
написание кода, позволяет сосредоточиться на алгоритме. Но мне вот очень интересно,
а можно ли вообще писать одну и ту же программу на разных языках? Делают ли так? Например,
писать все в императивном стиле - это по-моему не самая лучшая идея. Но и в функциональном
стиле вряд ли получится целиком большую программу написать. То есть функциональны и
императивный подход точно должны сосуществовать в больших программах, правильно? А
вот что насчет языка? Например, GUI и обращения к базе данных реализовать на java,
а всю бизнес-логику на erlang? Нет, сейчас конечно можно писать в функциональном стиле
и на java, но столько фишек как на erlang все равно не получишь. Например, erlang дает
очень большие возможности для распараллеливания. На java, даже используя добавленные
недавно лямбда таких возможностей для распараллеливания не добиться. В общем, интересует
следующее: возможно ли технически в одном проекте писать часть на erlang, а другую
на java? 
    

Ответы

Ответ 1

Не вижу ничего плохого в том, чтобы писать программу на нескольких языках, каждую
часть — на том, на котором удобнее. Вопрос стоит больше в том, удобно ли компоновать
части, написанные на различных языках.

Например, если языки, которые вы используете, опираются на общий рантайм, объединять
их легко (особенно если при этом языки создаются с рассчётом на interoperability).
Пример: языки на основе .NET (C#, Visual Basic, F#), языки на основе JVM (Java + Scala),
языки на основе C (C + C++): объекты одного из них можно без особенного труда использовать
в других.

С сильно разнородными языками связать модули сложнее. Обычно используют либо C в
виде общего знаменателя (Python, P/Invoke в .NET), либо обмен данными через текстовый
формат (Unix shell и его утилиты). Также часто применяются различные формы RPC (например,
AJAX по сути является таковым, и не стоит забывать COM).

Ещё одна часто используемая возможность — полная или частичная кодогенерация. Например,
Razor генерирует HTML, T4 и WPF генерируют исходники на C#.



По сути, сейчас и так многие программы пишутся на нескольких языках. Например, если
вы пишете веб-сайт на чём-то наподобие ASP.NET MVC, то вы используете C#, Razor, HTML,
Javascript и возможно Typescript в одном проекте.


Ответ 2

Можно. Попробуйте язык Katahdin


  Katahdin представляет язык программирования просто как инструмент, не
  ограничивая программиста в выборе платформы или библиотек. Каждый
  участок программы, отвечающий за конкретную задачу, может быть
  реализован на более подходящем языке программирования (в зависимости
  от задачи, разработчиков и используемых библиотек).
  
  Например, программа на Фортране, предназначенная для вычислений, может
  плохо справляться с некоторой обработкой текста, требуемой при
  вводе-выводе. В этом месте лучше использовать более подходящий язык,
  например, Perl. В программе на Katahdin код, обрабатывающий текст и
  написанный на Perl, может быть использован в том же файле, что и
  программа на Фортране.

nginx возвращает 502 Bad Gateway даже если приложение уже работает

На сервере настроена связка Nginx + Erlang. А именно - nginx слушает 80-й порт и проксирует запросы на порт 8738. Erlang с помощью Cowboy, принимает запросы с порта 8738 и отдаёт статику по http или обрабатывает сообщения по WebSocket. Вот кусок конфига, который за это отвечает:
# При запросе страниц бэковой части перебрасываем на эрланг location /back { # настройки проксирования на эрланг proxy_pass http://localhost:8738/back; proxy_set_header Host $host; # без особой надобности proxy_cache_valid 502 10s; # недолго кешируем ошибку "502 Bad Gateway", если эрланг ещё не запустился # всё что ниже нужно для работы вебсокетов proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; # передаём заголовок "Upgrade: websocket", если он пришел от клиента proxy_set_header Connection $connection_upgrade; # добавляем заголовок "Connection: Upgrade", если был передан заголовок "Upgrade: websocket" }
Это была предыстория. Вообще сейчас не важно что такое Erlang, Cowboy и WebSocket. Проблема вот в чём
После перезагрузки сервера получается так, что nginx стартует раньше чем erlang. Соответственно, nginx не видит ничего на порту 8738 и возвращает 502 Bad Gateway. Да вроде бы и норм, но когда erlang запускается, ситуация остаётся неизменной. Ошибка 502 так и будет возвращаться всегда. В логах nginx вот это:
2017/06/02 12:07:33 [error] 708#708: *899 connect() failed (111: Connection refused) while connecting to upstream, client: xxx.xxx.xxx.xxx, server: foobar.com.ua, request: "GET /back HTTP/1.1", upstream: "http://[::1]:8738/back", host: "foobar.com.ua"
Hotfix: просто сделать sudo nginx -s reload и сразу всё работает! Работает сколько угодно времени до первой перезагрузки.
Как побороть это?

Ответ

Проблема скорее всего в том, что nginx при загрузке резолвит localhost в IPv6 адрес, а ваш сервер слушает на IPv4 адресе. После перезагрузки конфига nginx повторно резолвит адрес и на этот раз резолвит IPv4 адрес.
Если Cowboy слушает на всех портах, то можно в настройках systemd указать nginx что бы он стартовал только после запуска Cowboy.

Как именно реализованы процессы в Erlang?

Вопрос несет сугубо академический характер. Собственно: Erlang is designed for massive concurrency. Erlang processes are light-weight (grow and shrink dynamically) with small memory footprint, fast to create and terminate and the scheduling overhead is low. Какие условия должны соблюдаться для того, что-бы было возможно реализовать подобную модель, какое API используется? В общем - как реализовать такого рода поведение средствами C/C++ или других языков? В первую очередь интересует не код, а теория. PS: Когда-то гуглил на эту тему, но, к моему большому удивлению, толкового ответа не нашел. Более того - многие писали о том, что реализовать подобную модель средствами С/C++ невозможно, во что мне верится с трудом.

Ответ

Будем считать, что речь идет о BEAM, потому что, вообще говоря, у Erlang была богатая история Начиная с R13 (см. презентацию Ульфа Вигера, стр. 19), при условии, что BEAM собрано с поддержкой SMP, создается несколько шедулеров (число определяется опцией +S, как они соотносятся с логическими процессорами определяется флагом +sbt), у каждого есть своя очередь процессов. Процесс — всего лишь структура данных, включающая в себя собственную независимую кучу, стек (даже два, в случае с HiPE, см. стр.4) и все положенные процессу регалии (мейлбокс, словарь процесса, тысячи всякого). Собственно, структуру struct process можно посмотреть в исходниках BEAM, в файле erl_process.h И, к вопросу многозадачности — шедулер реализует вытесняющую многозадачность, раз в определенное число редукций (по сути, операций) переключаясь на другой процесс. Какой-нибудь драйвер, как честно предупреждает документация — «this means that all operations in the driver must be non-blocking, and that any crash in the driver will bring the whole emulator down» — может завесить поток или вообще уронить всю VM. Вот, собственно, и все, вроде бы, если не лезть во всякие тонкости и детали (которых я и сам не шибко в курсе, т.к. потроха BEAM, можно сказать, никогда толком и не трогал).