Проблема в том, что conntect/accept это блокирующий вызов, и нельзя подключится к нескольким портам одновременно (одним сокетом)
Не до конца так. Штука в том, что если вы будете дергать accept на один и тот же сокет, но из разных тредов, ядро само все разрулит и запаркует ненужные треды «до лучших времен». С другой стороны, когда придет новое соединение оно разбудит сразу все треды, хотя по факту нужен только один. Так что, в любом случае, такой фокус применять не рекомендуется. По крайней мере, так это работает в Linux'е.
Знаю что это пост 13-го года… Но на случай если кто-то сюда случайно попадет так же как и я.
Ваши 2 выражения не идентичны. В первом случае auto выведется в тип int — все правильно. А во втором в…
coreutils/busybox — являются оберткой над кучей маленьких программ, каждая из которых выполняет только одну задачу.
gcc — выполняет одну задача — компилирует.
emacs — редактирует текст, несмотря на кучу дополнительных плагинов.
ядро — само по себе состоит из кучи модулей/процессов/etc., которые просто работают в одном адресном пространстве (если говорить о монолитных ядрах)
и т.д. и т.п.
systemd, в свою очередь, берет на себя кучу невзаимосвязанного функционала: инициализация, журналирование, управление устройствами и многое другое.
А еще нарушает один из канонов юникса — «программа должна выполнять только одну задачу, но выполнять ее хорошо» (цитата не дословная).
Слишком много функций systemd пытается на себя перетянуть, а от этого страдает надежность.
Все оно так, да не совсем. Было дело, заказали 5-ть таких китов с dx.com для демо на конференцию. Все компоненты как в описании, но:
1. Вместо Arduino приехал китайский клон: Funduino. У Funduino оказался нехилый баг: используя питание от китовых аккумов, на пин 5V подавалось 3.3V (при питании с USB — все нормально). Проблема очень критична для некоторых сенсоров, например, сонара (он работает только на 5-ти). Не знаю, был ли это брак, или это поголовная болезнь.
2. В комплекте одна плата драйвера L298N, а движков 4. При параллельном подключение 2-ух движков на один вход, все работает из рук вон плохо. Движки вроде одинаковые, а вот редукторы в каждом из них работают с совсем разной скоростью, при одинаковом напряжении. В итоге робот гребет в совершенно непредсказуемую сторону. Кроме того, при попытке поворота (два колеса вперёд, два — назад), робота неслабо сносит с оси.
3. Общая корявость сборки: движки закреплены на плате так, что после установки колёс те цепляют за края платы.
В результате пришлось в срочном порядке заменять шасси и Funduino на отдельно купленные оригинальные Arduino при тех же остальных запчастях. Получилось вот так:
Видео
Гораздо позже, после дополнительных доработок грубым напильником, вышло как-то так:
Фото
Резюме: как игрушка может и подходит, но геморроя от кита можно получить очень много.
Если Вы помните, C++ предоставляет множество парадигм и абсолютно не ограничивает их использование и даже смешивание. Конечно есть некий оверхед в использовании динамического полиморфизма. Но чем конкретно Вам не нравится подобный подход?
Тут Вы конечно правы — самому копаться придется очень много. Тем не менее, основы есть основы и базовые компоненты ядра (например та же обработка прерываний) существенно не меняются. Чаще всего добавляют новые стратегии и структуры данных, при этом от старых никто не отказывается.
Отлично написано, спасибо. «Ядро Linux. Описание процесса разработки» Р. Лава помогает разобраться с темой.
На мой взгляд, стоит также упомянуть о том, что минимальная необходимая логика внутри обработчика в top-half должна содержать ответ устройству о полученном прерывании, это must have всегда.
Я смотрю Вы никогда не работали с критичным к производительности кодом.
Делать некоторые вещи в рантайме может оказаться непомерно дорогим удовольствием. При этом нам по прежнему нужен толерантный к изменениям код. Тут на помощь приходят и статический полиморфизм (вспоминаем концепцию «стратегий» у Александреску А. «Современное проектирование на с++»), и вычисления на этапе компиляции.
Так никто и не говорил, что так надо делать :). А Ваш пример действительно ужас, так как memset вызывается уже после вызова конструктора. memset'ом можно инициализировать объекты, выделенные, например, с помощью malloc. Но опять таки этого никогда не стоит делать. В статье была просто проведена аналогия между структурами в Си и классами С++.
Кстати, для более глубокого понимания, очень рекомендую «Дизайн и эволюция С++» Страуструпа. Там описан и механизм, и то, что к такому решению привело.
Как минимум без libevent и boost::asio в POSIX'е есть poll(). Правда не во всех системах есть нативная его реализация (иногда это просто проксирование того же select'а)
Не до конца так. Штука в том, что если вы будете дергать accept на один и тот же сокет, но из разных тредов, ядро само все разрулит и запаркует ненужные треды «до лучших времен». С другой стороны, когда придет новое соединение оно разбудит сразу все треды, хотя по факту нужен только один. Так что, в любом случае, такой фокус применять не рекомендуется. По крайней мере, так это работает в Linux'е.
Знаю что это пост 13-го года… Но на случай если кто-то сюда случайно попадет так же как и я.
Ваши 2 выражения не идентичны. В первом случае auto выведется в тип int — все правильно. А во втором в…
Такая особенность выведение типов у auto.
Не совсем понял практику использования этих двух функций вместе. Может первое вместо второго? Или gethostbyaddr() вместо gethostbyname()?
coreutils/busybox — являются оберткой над кучей маленьких программ, каждая из которых выполняет только одну задачу.
gcc — выполняет одну задача — компилирует.
emacs — редактирует текст, несмотря на кучу дополнительных плагинов.
ядро — само по себе состоит из кучи модулей/процессов/etc., которые просто работают в одном адресном пространстве (если говорить о монолитных ядрах)
и т.д. и т.п.
systemd, в свою очередь, берет на себя кучу невзаимосвязанного функционала: инициализация, журналирование, управление устройствами и многое другое.
Улавливаете разницу?
Слишком много функций systemd пытается на себя перетянуть, а от этого страдает надежность.
1. Вместо Arduino приехал китайский клон: Funduino. У Funduino оказался нехилый баг: используя питание от китовых аккумов, на пин 5V подавалось 3.3V (при питании с USB — все нормально). Проблема очень критична для некоторых сенсоров, например, сонара (он работает только на 5-ти). Не знаю, был ли это брак, или это поголовная болезнь.
2. В комплекте одна плата драйвера L298N, а движков 4. При параллельном подключение 2-ух движков на один вход, все работает из рук вон плохо. Движки вроде одинаковые, а вот редукторы в каждом из них работают с совсем разной скоростью, при одинаковом напряжении. В итоге робот гребет в совершенно непредсказуемую сторону. Кроме того, при попытке поворота (два колеса вперёд, два — назад), робота неслабо сносит с оси.
3. Общая корявость сборки: движки закреплены на плате так, что после установки колёс те цепляют за края платы.
В результате пришлось в срочном порядке заменять шасси и Funduino на отдельно купленные оригинальные Arduino при тех же остальных запчастях. Получилось вот так:
Гораздо позже, после дополнительных доработок грубым напильником, вышло как-то так:
Резюме: как игрушка может и подходит, но геморроя от кита можно получить очень много.
Если Вы помните, C++ предоставляет множество парадигм и абсолютно не ограничивает их использование и даже смешивание. Конечно есть некий оверхед в использовании динамического полиморфизма. Но чем конкретно Вам не нравится подобный подход?
На мой взгляд, стоит также упомянуть о том, что минимальная необходимая логика внутри обработчика в top-half должна содержать ответ устройству о полученном прерывании, это must have всегда.
Делать некоторые вещи в рантайме может оказаться непомерно дорогим удовольствием. При этом нам по прежнему нужен толерантный к изменениям код. Тут на помощь приходят и статический полиморфизм (вспоминаем концепцию «стратегий» у Александреску А. «Современное проектирование на с++»), и вычисления на этапе компиляции.
Это все к тому, что шаблоны в C++ ну оочень мощный интсрумент.
Это как же Вы архитектурно достигнете:
а) вычислений во время компиляции
б) автоматической генерации кода
?