Drive your career as React Developer with Symphony Solutions!
×Закрыть

А требуется ли в современном мире опыт libevent/libuv/... ?

За последние пять лет я встречал аж одну вакансию. Или я не там смотрел?

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Не зрозуміло про який контектс іде мова.
Про c10k problem, чи про що?

Скорее о серверах разрабатываемых на конкретной технологии.

А мы таки продаем библиотеку или домен ее использования?

Я пробовал и так и иначе — не взлетело. Именно поэтому я и пришел сюда.

Сегодня в вакансиях бред не все могут нести. Вернее нести могут не только лишь все. Каждый может это делать.
Так что мой совет, не стесняйся поговорить по каждой. Очень часто они формируются тупо копипастой, без малейшего понимания что им вообще надо. Лишь бы баззворды.

Так что мой совет, не стесняйся поговорить по каждой.

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

Есть разные подходы примерно с одинаковой производительностью. nginx+fcgi вполне себе ничего, и ручками сокеты дергать не надо.
Это если о производительности, а не о количестве соединений, сорри.

Так у nginx внутри уже готовый свой аналог. Естественно, что его писать уже не надо :)

Нужен опыт событийно-управляемого написания на C/C++ в целом.
Конкретно при этом требовать libuv или кого-то ещё смысла достаточно мало, они все плюс-минус взаимозаменяемы. Хотя Boost ASIO часто пишут явно, но это по сути сокращение для «event-driven low-level C++ I/O».
Так что при желании продолжить такой опыт я бы советовал освоить ASIO и смотреть вакансии по нему. На C такие вещи уже мало пишут :(

Нужен опыт событийно-управляемого написания на C/C++ в целом.

Где и как? На linkedin, dou/djinni, stackowerflow я встречаю такого рода вакансии реже чем раз в году.

Хотя Boost ASIO часто пишут явно, но это по сути сокращение для «event-driven low-level C++ I/O».

ASIO это крохотный low-level модуль осваиваемый за вечер и его пишут явно. libevent это ни разу не крохотный и не low-level — и тишина?

Так что при желании продолжить такой опыт я бы советовал освоить ASIO и смотреть вакансии по нему. На C такие вещи уже мало пишут :(

Если судить по количеству обсуждений на тому же стэк-оверфлоу то ситуация прямо противоположная. Общее количество упоминаний в Google — приблизительно одинаковое. Хотя я посмотрю на ASIO — а вдруг?

libevent это ни разу не крохотный

все что меньше гигабайта исходников это крохотный

Где и как? На linkedin, dou/djinni, stackowerflow я встречаю такого рода вакансии реже чем раз в году.

Когда я включил в профиль на djinni просто event driven programming, мне поступило запросов пять сразу с упоминанием ASIO.

ASIO это крохотный low-level модуль осваиваемый за вечер и его пишут явно. libevent это ни разу не крохотный и не low-level — и тишина?

Дядьку, вы ничего не попутали? С каких пор это стало «крохотный low-level модуль» и почему это он у вас «крохотный», когда libevent «не крохотный»? Мы вообще про тот же libevent или другой? Если да — то они друг другу равны по уровню, а по возможностям — до пары процентов. А тем более если ещё libuv упоминать с тем же набором.

Если судить по количеству обсуждений на тому же стэк-оверфлоу то ситуация прямо противоположная.

Количество обсуждений на SO это популярность умноженная на диверсионность (которая вылезает в виде плотности WTF), а не просто популярность. В случае libevent... Провос хороший человек, но дизайнер библиотеки из него хреновый, мягко говоря. После ISC eventlib, от его libevent меня натурально тошнило. (libev, libuv хоть как-то это нормализовали... но для разработки под C++03 я вообще сделал самопал за два дня по мотивам Python asyncore и оно хорошо работало и было всяко удобнее этих кошмариков.) Так что для начала надо количество сообщений по libevent разделить на три и только после этого сравнивать..

Когда я включил в профиль на djinni просто event driven programming, мне поступило запросов пять сразу с упоминанием ASIO.

Вау. Так понятней. Я на djinni выибирал скилы исключительно из предложенных djinni, а оказывается что там можно создавать свои.

С каких пор это стало «крохотный low-level модуль» и почему это он у вас «крохотный», когда libevent «не крохотный»? Мы вообще про тот же libevent или другой? Если да — то они друг другу равны по уровню, а по возможностям — до пары процентов. А тем более если ещё libuv упоминать с тем же набором.

Boost.asio это просто узко-специализированный слой абстракции. Ни больше ни меньше.

Но в той же же libevent один http-парсер чего стоит. А libuv это вообще половина Node.js-а.

Boost.asio это просто узко-специализированный слой абстракции. Ни больше ни меньше.

Какой абстракции?

Вот я на нём написал: создать контекст, создать сокет, включить его в контекст, включить слушание входящих соединений. На каждое соединение читаю строку, отдаю строку обратно, закрываю соединение. Это через объекты типа «контекст» (io_service), «сокет», функциями типа «я отсюда читать буду, вызови мне коллбэк с результатом» и т.п.

Какая разница между ним и другим аналогичным движком событий, который в себя собирает сокеты, таймеры и прочее?

По-моему, вы его вообще не видели. Я всё-таки на нём писал (а также на libuv и на своём asyncore-style аналоге, а для libevent писал тестики и по их результатам расплевался, и на той же ISC eventlib — это было вкуснее всего).

Но в той же же libevent один http-парсер чего стоит. А libuv это вообще половина Node.js-а.

Эээ...

Про libuv — вы, наверно, про что-то более обширное говорите (только непонятно, где оно). Вот я развернул libuv-libuv-v1.35.0_GH0.tar.gz — там только движок событий, «половины nodejs» как-то не видно. Заглянул на github.com/libuv — там тоже не видно ничего похожего на «половину nodejs» — которым в первую очередь должно было бы быть, например, V8, парсер JS и т.п.
Вы точно не путаете?
Ну да, там чуть больше — самостоятельные async-потоки и интерфейс вокруг FS. Хотя толку с него копейки (кроссплатформенность).

libevent — да, если развернуть сорцы, http парсер там есть. Хотя в книге об этом не сказано (иначе должно было быть сказано на входной странице), и я склонен считать, что если оно недокументировано — то его нет. Но если его и считать — то это один не сильно крупный и полезный компонент. Даже на входной странице сказано про «fast and scalable replacement»... :))

Суммируя — разница минимальна, всё это почти близнецы.

Вы точно не путаете?

Каюсь. Так и есть. На проэкте где я пользовал libuv он был выдран с node.js «с мясом», а не в чистом виде как на github. Вобщем теперь соглашаюсь — разница не такая большая.

В случае libevent... Провос хороший человек, но дизайнер библиотеки из него хреновый, мягко говоря. После ISC eventlib, от его libevent меня натурально тошнило.

Скажем, я бы на его месте как минимум API спроэктировал бы в традиционном для event-driven стиле.

Этого не понял, можно расшифровать?

Попробую. Ты определенно знаешь что существуют различные парадигмы программирования. Ну процедурная, функциональная, реактивная. Event-driven это еще одна парадигма, со своей теорией, мат-аппаратом, инструментами, традициями и практиками. Товарищ Провос повел всех по самому непрактичному пути.

Тут надо бы таки больше подробностей. Про теорию, матаппарат — в пределах возможностей этих библиотек я не вижу его выше школьной арифметики. И в каких библиотеках/фреймворках, по-твоему, оно лучше?

Посмотри на QP: www.state-machine.com/qpc

Тоесть если бы Провос пошел тем же путем мы бы получили технологический прорыв в программировании.

Акторы.
Акторы это другое. На них свой спрос и свои 100500 реализаций.
Но работать акторы всё равно будут поверх подложки стиля всё тех же ASIO/libevent/etc. — это просто разные уровни. «Непрактичного» в подложке нет, просто поверх неё надо что-то другое строить, когда и где надо.

Реально у меня в текущем проекте что-то издалека похожее наколенное. Но вот осталось злобное легаси нескольких видов — часть взаимодействий идёт асинхронно, а часть — синхронно. Вместе получается достаточно парадоксальный эффект. Может, осилим в этом году разобраться...

А ты видел SObjectizer? Да, C++.

Но работать акторы всё равно будут поверх подложки стиля всё тех же ASIO/libevent/etc. — это просто разные уровни.

Обьясню по другому: типичная нормальная реализация акторов не может быть состыкована с libevent без прослойки. При этом никакой обьективной необходимости для проэктирования libevent именно таким способом — не существовало.

А ты видел SObjectizer? Да, C++.

Последние лет 7 небыло необходимости в подобном — всё крутилось вокруг WEB-a. До этого — мы пришли к заключению что наиболее оптимальным является писать код на языке умеющем акторы, с последующей трансляцией в С. Алгоритмы описанные аппаратом акторов одинаково эффективно транслируются во что угодно.

Обьясню по другому: типичная нормальная реализация акторов не может быть состыкована с libevent без прослойки. При этом никакой обьективной необходимости для проэктирования libevent именно таким способом — не существовало.

Здесь бы пример хотя бы на десяток строк, но реально та прослойка... ну даст ещё сотню-другую строк, по сравнению со всей ценой толковой библиотеки акторов это не сильно много.
А в остальном про стиль libevent я уже высказался.

мы пришли к заключению что наиболее оптимальным является писать код на языке умеющем акторы, с последующей трансляцией в С.

Да, вполне возможно.

У меня не веб, у меня SIP и прочие аналогичные ужасы :) там другая специфика, в основном на то, как попытаться чудовищный бред в правилах организации взаимодействий выгнуть до чего-то такого, что можно таки закодировать.

Я написал Actors на коленках за 2-3 недели поверх pthread. Правда, живут в одном процессе, а не сервер. Нормального легковесного фреймворка не смог найти, самым полезным для прототипирования был libraries.io/nuget/libting

Извиняюсь но акторы на pthread имеет исключительно образовательную ценность.

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

Когда у тебя несколько телефонных звонков, и нажатия кнопок надо обрабатывать не блокируясь, параллельно с голосом, сокетами (SIP) и файлом истории звонков — ты иначе систему просто не сделаешь.

На той платформе с которой я имел дело — без проблем. Не секрет какая у тебя платформа?

Я имел ввиду модели железа и версии софта. Вы же не реализовали DECT собственными руками? Да и SIP-стэк скорее всего готовый взяли ...

RTX USB DECT dongle + pjsip + (ProSLIC+EFM32HG)

У меня был очень похожий проэкт на риалтэке. В том проэкте обьективной необходимости использовать мульти-трединг небыло.

Расскажи.
Здесь достаточно одного того, что каждые 20 мс надо протягивать до 4 голосовых пакетов в две стороны, при этом работа с файлами и с телефонной книгой. Два последних действия могут занимать больше 20 мс.

Так понятней. У нас весь звук обрабатывался отдельным чипом, если не изменяет память — DSP от DSPJ с ихней же прошивкой. Под линуксом крутились только управление звонками + телефонная книга.

А в сеть кто голос отправляет? тоже DSP?

Честно — не запомнил. Возможно это было реализовано отдельным IP-ядром на SOC.

А у нас — это все на обычном WiFi роутере с USB разъемом. DSP есть в донглах, но DECT NWK layer самописный, и звук протягивать между pjsip и донглом тоже самим надо. А еще год назад сказали добавить поддержку FXS.

Вообщем железо у нас было лучше. А софт скорее всего у вас.

У вас было специализированное железо. У нас — пользователь WiFi роутера не платит за телефонию и железо к ней, пока не купит донгл. Типа «легким движением руки роутер превращается... превращается... превращается в телефонную станцию».

The behavior of active objects is specified in QP/C by means of hierarchical state machines (UML statecharts). The framework supports manual coding of UML state machines in C as well as automatic code generation by means of the free QM™ modeling tool.

Кодогенераторы? А я думал — они уже лет 20 как мертвы. Нет, кто-то занялся зомбовирусом.

Кодогенераторы? А я думал — они уже лет 20 как мертвы. Нет, кто-то занялся зомбовирусом.

Кажется Денис Ритчи говорил — «все что может быть сгенерировано — должно быть сгенерировано»

Видел книжку с имплементацией ООП на С?
Вот лучше не смотри. Там тоже кодогенерация.
Вместо этого выжил С++ без кодогенерации и сильно нерекомендующий макросы.

Гугл написал Protobuf на С++ (и некоторых других) с кодогенерацией

Один нишевый проект? Логику писать на кодогенераторах давно перестали из-за того, что потом нагенеренное кому-то дебажить)

любой код надо дебажить, чем нагенеренный хуже

Тем, что ты его не писал и даже не называл в нем переменные.
Соответственно, это — как код, писаный десятью джунами из Индии после гашиша.

Ну подебажь выхлоп yacc (bison, byacc — неважно).
Там будет штатный движок, постоянный на все случаи, таблица твоих дефайнов и несколько массивов из чисел — таблицы переходов и т.п.
Успехов в чтении стека состояний, когда даже непонятно, какое число за что отвечает, и это может меняться при каждой перегенерации в ответ на малейшие изменения кода :)

Такое можно отлаживать только визуальным анализом самой грамматики на типовые грабли, которые знает тот, кто в этой области съел хотя бы пол-собаки, и тестами.

В норме смотреть в сгенерированный код не нужно, если ты не разработчик его кодогенератора. Смотреть нужно в исходники, из которых он генерируется

тогда надо дебаггер, который мапит сгенеренный код обратно на исходники. как gcc мапит машинные инструкции на код.

Это детский сад. Ну если не считать студентческих поделок.

Я лично в такое не умею и не хочу.

Ну вообще-то удобнее FSM писать на некотором входном языке, парсер которого ещё проверит корректность по нужным тебе критериям, а дальше сам нарисует все нужные if’ы и т.п.

(Рядом я упомянул всякие lex/yacc, где тоже генерация это норма, но это немного другой контекст.)

Может, у вас другая специфика задач, но мне FSM (паттерн) пригодился аж один раз месяц назад. Все, что видел до этого — SM сильно портил код, и понять происходящее становилось нереально.

Я на FSM, акторы и подобное потратил лет 10 или чуть больше

А я в FSM вообще не умею. Я их боюсь.

libevent и libuv конечно же нужны, но Ъ-сеньор может их быстро освоить с нуля по мере надобности, так что указывать их в вакансиях не очень рационально

не треба, це взагалі дивно вимагати знання і досвід з якоюсь конкретною лібою (нажаль це часто зустрічається в оголошенях). Бо ліб вже є тисячі о розбиратися з кожною треба коли виникне потреба
а от вимагати треба знання підходів і досвід який дозволить вибрати потрібну архітектуру і підібрати ці ліби

Требование опыта с той же Qt встречается регулярно. Или, например, вы в своих скилах подчеркиваете NDK.

Qt — то фреймворк, а не ліба. Він здоровий, та написання коду під нього має певну специфіку.

Уточню — у меня опыт с обеими измеряется годами.

Я сомневаюсь что будут вакансии libevent developer, ну и это не такая сложная штука для упоминания в вакансии.

Есть вакансии React developer :)
JS мир не стоит на месте, он падает еще глубже на дно :)

Эххх ... Я не думаю что опыт фронтенда применим к фундаментальным вещам.

Требование опыта с той же Qt встречается регулярно.

Между Qt и libevent есть существенная разница. libevent штука нишевая и если не быть совсем ленивым, то реализовать ее функционал не трудно, а вопрос переносимости чаще всего вторичен. Qt это целая инфраструктура, штука самодостаточная, с кучей своих свистелок и перделок.

libevent штука нишевая и если не быть совсем ленивым, то реализовать ее функционал не трудно, а вопрос переносимости чаще всего вторичен.

про нишевость согласен, это очевидно. Но на тему «нетрудно» — крайне не согласен. Среднестатистический сеньйор за разумное время ничего эквивалентного не провернет.

Саму libevent в її повноцінному вигляді, звичайно, буде дуже важко реалізувати. Але воно і не потрібно. В кожному окремому проекті малого чи середнього масштабу буде потрібно 10% її функціоналу і от їх написати можна (і багато хто писав).

Ну сделать обвертку вокруг epoll() как бы не вопрос. Но на libevent за вечер можно сваять нормальный вэб-сервер. Я хочу посмотреть как ты это будешь делать голыми руками.

Ось Ви і відповіли самі на питання, яке ставили в статті. В кожному випадку, коли можна написати обгортку над epoll — люди будуть писати обгортку над epoll. А вакансії на libevent будуть відкривати ті, кому потрібен свій веб-сервер. Пропорція перших і других — очевидна.

Подписаться на комментарии