Комментарии 9
Я думаю стоит подумать над тем, чтобы таким образом реализовать обертку для динамической загрузки библиотек в никсах.
Чёрт, как долго я вас ждал со статьями про Inferno!
Вопрос к автору. А какого рода задачи вы решаете с помощью Inferno/Limbo.
Если возможно на примерах… Очень было бы интересно узнать.
Если возможно на примерах… Очень было бы интересно узнать.
В основном анализ/обработка большого потока данных.
Но мой выбор Inferno/Limbo был обусловлен не столько типом задач, сколько желанием облегчить себе жизнь — Inferno/Limbo позволяет писать намного более простой код, что экономит массу времени и сил как при разработке, так и при поддержке этого кода.
Хотя у нас в проекте много самых разных задач, большинство из них должно делать одновременно много разных вещей — от обычного fastcgi сервера обслуживающего параллельно нескольких пользователей (работающего на одном ядре) до сетевых сервисов распределённой обработки данных (работающих на кластере серверов). Изначально всё это писалось на Perl, в событийно-ориентированном стиле, на базе epoll и callback-ов. Код в таком стиле по определению получается достаточно сложным, хотя и вполне эффективным. Единственный способ действительно упростить разработку таких приложений — писать многопоточные приложения в стиле CSP. А это означает либо Limbo, либо Go, либо что-нить не менее экзотичное вроде C под Plan9/p9p.
По сравнению с C Limbo даёт проверку типов, высокоуровневые примитивы, управлению памятью…
По сравнению с Go, проекты на Limbo несколько сложнее deploy-ить (впрочем, если на свои сервера, то один раз настроить, и дальше никаких проблем), но зато на Limbo значительно проще писать из-за того, что код выполняется в намного более простой среде OS Inferno, а не обычного *NIX — нет неблокирующего I/O, нет сигналов, etc. и в результате в коде приходится учитывать намного меньше странных особых случаев, возникает меньше странных багов, плюс есть дополнительные фишки самой Inferno в виде Styx/9P, возможности удалённо отлаживать работающие или уже упавшие процессы, …
Вот и получается, что проще всего писать именно на Limbo, из имеющихся на данный момент вариантов.
Но мой выбор Inferno/Limbo был обусловлен не столько типом задач, сколько желанием облегчить себе жизнь — Inferno/Limbo позволяет писать намного более простой код, что экономит массу времени и сил как при разработке, так и при поддержке этого кода.
Хотя у нас в проекте много самых разных задач, большинство из них должно делать одновременно много разных вещей — от обычного fastcgi сервера обслуживающего параллельно нескольких пользователей (работающего на одном ядре) до сетевых сервисов распределённой обработки данных (работающих на кластере серверов). Изначально всё это писалось на Perl, в событийно-ориентированном стиле, на базе epoll и callback-ов. Код в таком стиле по определению получается достаточно сложным, хотя и вполне эффективным. Единственный способ действительно упростить разработку таких приложений — писать многопоточные приложения в стиле CSP. А это означает либо Limbo, либо Go, либо что-нить не менее экзотичное вроде C под Plan9/p9p.
По сравнению с C Limbo даёт проверку типов, высокоуровневые примитивы, управлению памятью…
По сравнению с Go, проекты на Limbo несколько сложнее deploy-ить (впрочем, если на свои сервера, то один раз настроить, и дальше никаких проблем), но зато на Limbo значительно проще писать из-за того, что код выполняется в намного более простой среде OS Inferno, а не обычного *NIX — нет неблокирующего I/O, нет сигналов, etc. и в результате в коде приходится учитывать намного меньше странных особых случаев, возникает меньше странных багов, плюс есть дополнительные фишки самой Inferno в виде Styx/9P, возможности удалённо отлаживать работающие или уже упавшие процессы, …
Вот и получается, что проще всего писать именно на Limbo, из имеющихся на данный момент вариантов.
Спасибо за продолжение инфернального цикла статей, я уж боялся, что Вы забросили эту тему… Вопрос немного в сторону от текущей статьи: не могли бы Вы написать о том, как можно было бы эффективно решить какую-либо общеизвестную задачу в инферно? Ну скажем, написать простенький веб-сервер, или что либо подобное. Без исходных кодов, но с описанием того, как бы это работало архитектурно. Мне кажется, именно такой статьи сейчас не хватает :)
Веб-сервер — это, в основном, TCP-сервис плюс парсинг/генерация HTTP-заголовков. Эта функциональность реализуется везде одинаково. Проксирование запросов к FastCGI/SCGI/etc. серверу по тому же TCP тоже делается как обычно. Максимум, где можно поиграться с Inferno-специфичными вещами — в настройке/контроле самого веб-сервера через виртуальную FS и в подгрузке/выполнении CGIшек как Limbo-модулей (что тоже не так уж уникально, и напоминает mod_perl/mod_php, только реализованный намного проще). Так что это не самый удачный пример. У Mechiel (mjl) помимо прочего софта под Inferno есть и реализация веб-сервера — можете глянуть код.
Архитектура может быть Inferno-специфичной и любопытной скорее у разных служебных утилит, которые работают исключительно внутри Inferno, а не как внешние TCP-сервера. Например, watchdog, который мониторит работающие процессы (как уже существующие, так и запускаемые им самим) и выполняет заданное действие есть процесс падает; retrymount, который встраивается между стандартной командой mount и 9P-сервером как прокси, чтобы контролировать состояние соединения и перезапускать mount есть соединение разорвалось; etc.
Есть задачи, которые очень сложно решать в других системах, и которые очень просто решаются в Inferno — например, построение системы распределённых вычислений буквально на коленке, средствами sh-скриптов: Простой пример Grid. Но у меня своё отношение к таким примерам. Да, они реально рабочие, да, они наглядно демонстрируют особенности Inferno, но… я пишу код для production, а это значит обработка ошибок, логи, мониторинг, автоматические переподключения к узлам, повтор провалившихся заданий, и т.д. и т.п. что превращает эти простые наколеночные скрипты в полноценные большие приложения, далеко не столь наглядные, зато надёжно работающие.
Архитектура может быть Inferno-специфичной и любопытной скорее у разных служебных утилит, которые работают исключительно внутри Inferno, а не как внешние TCP-сервера. Например, watchdog, который мониторит работающие процессы (как уже существующие, так и запускаемые им самим) и выполняет заданное действие есть процесс падает; retrymount, который встраивается между стандартной командой mount и 9P-сервером как прокси, чтобы контролировать состояние соединения и перезапускать mount есть соединение разорвалось; etc.
Есть задачи, которые очень сложно решать в других системах, и которые очень просто решаются в Inferno — например, построение системы распределённых вычислений буквально на коленке, средствами sh-скриптов: Простой пример Grid. Но у меня своё отношение к таким примерам. Да, они реально рабочие, да, они наглядно демонстрируют особенности Inferno, но… я пишу код для production, а это значит обработка ошибок, логи, мониторинг, автоматические переподключения к узлам, повтор провалившихся заданий, и т.д. и т.п. что превращает эти простые наколеночные скрипты в полноценные большие приложения, далеко не столь наглядные, зато надёжно работающие.
По поводу вебсервера — есть еще тема параллельной обработки входящих запросов. В традиционных системах это реализуется либо на форках (апач), либо через стейт-машину (нжинкс). Что с инферно, тупо использовать модель апача на инфернальных нитях, а остальное сделает сама система? Есть ли резон использовать стейт-машину? Или есть свой нативный путь?
Примеры обязательно посмотрю, спасибо.
Примеры обязательно посмотрю, спасибо.
Да, конечно, на нитях. Это и есть свой нативный путь. Нитей много, они очень лёгкие, обмен информацией между нитями тривиальный — поэтому при любой возможности упростить логику выкинув её часть в отдельную нить — делают именно это. И никаких больше FSM для I/O. FSM намного сложнее в реализации, и необходимость в ней вызвана исключительно дороговизной процессов и сложностью взаимодействия между нитями в *NIX/Win.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка модулей для Limbo на C (часть 1)