>Про timerfd и heap~ы не понял, можно развернуть мысль?
Как правило, все таймеры можно объединить в heap (по-русски это вроде «пирамидой» называют). Однако, если таймерами управляет приложение, оно может объединить равноинтервальные таймеры в связанный список, привязанный к единственному элементу heap-а. В итоге rearm таймера будет иметь сложность O(1) вместо логарифмических вставки/удаления в heap. Именно поэтому я весьма скептически отношусь к помещению десятков тысяч таймеров в kqueue.
>Меня вот напрягло что запись+чтение могут придти разом, и udata для них никак не разделяется, этот код я так и не отладил, оставив рабочим вариантом когда один описатель — один тип событий.
Хранить в udata файловый дескриптор, а в userspace к файловому дескриптору привешивать цепочки watcher'ов, как это сделано в libev
>Кстати, sendfile() в линухе тоже весь такой обрезанный: не умеет данные до/после файла из буферов посылать
Но зачем? TCP_CORK + send/writev. Зачем плодить лишние сущности которые делают то же, что уже существующие? Цена syscall-а не такая высокая, как это многим кажется.
> Те превратить kqueue() в epoll() может любой дурак, тут ума совсем не надо.
В современном ядре Linux epoll обладает практически всеми фичами kqueue (за исключением, пожалуй EVFILT_PROC). Конечно, иногда это происходит ценой написания большего количества кода, но результат получается весьма достойным.
Кстати, использование timerfd для таймеров говорит о том, что не каждый дурак способен способен реализовать таймеры эффективно: в реальных приложениях, как правило, нужны таймеры, срабатывающие через равные промежутки времени, что можно сделать за O(1) в отличие от бездумного использования heap'ов для всего и вся.
>но вот отдачи много: 2-16 мегабит в одно соединение. И куча таких вот соединение, «проксирование» IPTV потоков один-к-многим
Я абсолютно не сведущ в FreeBSD-специфичных API, но как раз для этого в Linux завезли: a) splice (-30% cpu load при проксировании «один к одному») б) vmsplice (для отдачи кучи мегабит из одного соединения, для мультиплексирования) в) tee (для мультиплексирования «с трюкачествами»)
С некоторыми оговорками:
— до тех пор, пока хватает производительности одного ядра
— до тех пор, пока оперативной памяти хватает для хранения данных
Ну и при сборке статистики нужно иметь в виду, что ввиду однопоточности сервера, обработка данных прямо внутри сервера будет блокировать его работу (придется время от времени звать box.fiber.sleep(0), что может привнекти некоторые нежелательные эффекты — до сих пор не уверен, что будет с итератором, ссылающимся на tuple, который был удалён во время такого вот sleep-а).
Как по мне, статистику в тарантуле удобней агрегировать (можно еще WAL отключить), а работать с результатом все-таки удобнее в реляционной СУБД, где для join'ов не требуется программировать.
Offtop: однажды я выключил javascript в настройках браузера и поразился тому, насколько быстро стали отображаться все сайты. Мораль: поменьше анимаций, параллаксов и прочих рюшечек, назначение которых раздражать пользователя и затормаживать браузер.
Выше я приводил цитаты из стандарта языка C, где черным по белому написано, что в конструкциях &ptr->field и &*ptr никаких разыменований нет. И даже есть сноска, специально поясняющая, что &*(int*)NULL — это ок с точки зрения языка.
В C++ есть нюансы, называемые «перегрузка операторов», где может встретиться вызов виртуальной функции, что требует валидного объекта для чтения vmt. Поэтому в плюсах &objptr->field действительно в общем случае UB. В C же отсутствие UB в таких случаях гарантировано стандартом.
Большая ошибка полагать, что C — это как C++ (и делать на основании этого выводы), только без классов, оверлоадинга и перегрузки операторов. Это разные языки, но с похожим синтаксисом.
Я ни в коем случае не лезу в язык C++ — у него свой стандарт, гораздо более сложный и объемный. И я совершенно согласен, что в C++ для произвольного объекта выполнять «->» опасно, т. к. перегруженный оператор может вызывать виртуальные функции/обращаться к полям объекта, что приведет к «invalid behaviour».
Однако я цитирую стандарт C и linux kernel, фрагмент кода которого приводится, написан на языке C, по стандарту которого UB нет.
Хочу еще раз заметить, что все ваши рассуждения сводятся к «объект не может находится по адресу NULL», чего в стандарте явно не написано (см ваш перевод и оригинальный текст, которые я привел).
>перевешивают мнение таинственного dimoclus без единой публикации
Будьте любезны не скатываться на личности и уж тем более не приводить число публикаций на хабре в качестве объективного критерия компетентности.
Я не придумываю. Я привел две цитаты из стандарта, которые трактуются весьма однозначно и не оставляют поля для маневра.
В плюсах для не POD-типов есть нюасны, но стандарт плюсов — это совсем другая история.
Приведенная вами цитата
в Разделе 6.3.2.3 «Указатели» сказано следующее:
Если константа нулевого указателя приводится к типу указателей, то результирующий указатель, называемый нулевым, гарантированно будет не равен указателю на любой объект или функцию.
рекомендуется к повторному прочтению на языке оригинала:
If a null pointer constant is converted to a
pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal
to a pointer to any object or function.
Это означает, что any_valid_object_or_function_pointer != NULL всегда истинно.
Трактовка «нулевой указатель не указывает на объект, поэтому к его полю нельзя обратиться даже для вычисления адреса» смахивает на подмену понятий.
Вообще говоря, давайте вместе почитаем вот это (6.3.2.1 Lvalues, arrays, and function designators, п 2):
Except when it is the operand of the sizeof operator, the _Alignof operator, the
unary & operator, the ++ operator, the — operator, or the left operand of the. operator
or an assignment operator, an lvalue that does not have array type is converted to the
value stored in the designated object (and is no longer an lvalue); this is called lvalue
conversion.
Я долго думал, а потом прочитал это как
Кроме случаев, когда lvalue является аргументом операторов sizeof/alignof/унарного &/инкремента/декремента или левой частью оператора «.» или присваивания, lvalue, не являющееся массивом, преобразуется к значению, хранящемуся в означенном объекте.
Это по факту говорит нам, что чтения значения из lvalue при взятии от него адреса не происходит (а также sizeof(podh->line6), _Alignof(podh->line6)) => нет никакого разыменования => нет UB.
Что-то я крайне сомневаюсь, что тут есть какое-то UB.
Читаем стандарт, нам понадобятся два пункта:
6.2.5 Types
A structure type describes a sequentially allocated nonempty set of member objects
6.5.3.2 Address and indirection operators
The unary & operator yields the address of its operand. If the operand has type ‘‘type’’,
the result has type ‘‘pointer to type’’. If the operand is the result of a unary * operator,
neither that operator nor the & operator is evaluated and the result is as if both were
omitted.
Первый переход просто «по определению», второй — потому что структуры состоят из «последовательно расположенных непустых полей», ну а (3) даже специально прокомментирован в стандарте (страница 89, сноска 102 внизу страницы):
Thus, &*E is equivalent to E (even if E is a null pointer)
Каждый программист должен знать, что ни один компилятор не сможет заменить пузырьковую сортировку на quick/heap/mergesort, поэтому разработчику следует сосредоточиться на алгоритме, а об использовании кеша/выделении регистров нужно задумываться не раньше запуска профайлера.
Писать, уж простите, кучу говнокода, сваливая в кучу boost::tuple, boost::variant, std::map<std::string, std::vector<std::set<..>>>, уповая на силу аббревиатур PGO и LTO ни в коем случае нельзя.
P. S. навеяно непреодолимой тягой немалого количества C++-программистов приёмам из однострочников на perl/python/ruby (посчитать количество запятых в строке? Легко: string.split.size() и т. п.)
Никогда не пойму 10 типов людей: тех, кто парсит html регэкспами и тех, кто регулярками рефакторит.
Благодаря clang есть свет в конце тоннеля: github.com/bbchung/clighter помимо семантической подсветки умеет семантическое преобразование. К сожалению, пока работает не всегда корректно + чтобы переименовать сивол во всем проекте, нужно открыть все требуемые файлы. Но есть надежда, что дальше будет лучше.
совершенно внутренняя вещь, такая, как конкретная реализация работы с hashtable
А как же бинарная совместимость (собственноручно написанных) нативных расширений? Подобные проблемы вылезут в виде segmentation fault черте где, а не в виде сообщения интерпретатора о синтаксической ошибке, так что не бекпортировать такие вещи вполне разумное решение.
А не отпугивает от потоков, кхм, некоторая многословность?
printf("%.2f\n", count * 100.0 / total);
vs
std::cout << std::setprecision(2) << std::fixed << count * 100.0 / total << std::endl
+ во времена g++ 3.3-4.0 в ostringstream была утечка памяти — с тех пор отношусь к ним с большой подозрительностью
Vim-режим включается в настройках. Этот режим чего-то нужного не эмулирует?
Это сложно объяснить тому, для кого «модальное редактирование», имеет два состояния: бибикать после нажатия и все портить после .
vim — единственный на сегодня редактор, делающий упор на модальное редактирование. Современные IDE очень далеко шагнули в плане рефакторинга, навигации, дополнения кода — без всего этого они просто notepad.exe, а модальный режим там реализован убого и, скорее, «для галочки». Эти notepad'ные кишки постоянно вылезают в самое неподходящее время: в коде символ «some_long_function_name», а нужно сделать из нее «some_not_so_short_name»? Жмем «f_lc2t_not_so_short», чтобы перейти к началу «long», а затем удалить все до «_» перед «name» понадобилось всего три команды:
найти «_» (f_)
двинуться на символ вправо (l)
удалить весь текст до второго «_» и перейти в режим редактирования (c2t_)
Когда начинаешь воспринимать редактирование не как «удалить 20 символов», а «удалить три следующих слова» или «очистить до «)», все становится значительно быстрее и, главное, ошибок становится меньше.
Что в данном случае подразумевается под «отладкой»? Пошаговая трассировка в отладчике — да, это может быть затруднительно, если макрос сплошь состоит из вызовов функций. А вот в плане отладки «во что это экспандится» макросы на много голов выше шаблонов: начиная от gcc -E и заканчивая отладкой макроэкспанда в gdb.
P. S. только слепые рабы Саттера и Александреску боятся макросов, нормальные разработчики используют все доступные средства для повышения выразительности и читаемости кода.
Какая-то странная терминология. apr_pool_t — это то, что в статье называется «песочницей». Что же в статье называется пулом, мне так и осталось непонятно.
P. S. судя по всему «песочница» — это heap (http://en.wikipedia.org/wiki/Memory_management#HEAP)?
P.P.S. talloc.samba.org
/me вспоминает пальцы Линуса, его опусы про gcc-4.9 и многое другое.
А не путаете ли вы часом англоязычныую опенсорсную среду с платной поддержкой какого-нибудь RedHat'а, где специально обученные люди ни в коем случае не будут называть недалекого клиента так, как он того заслуживает?
Кхм…
curl -s http://repository.sandbox.infoboxcloud.ru/scripts/docker/centos7/install.sh | bash -e
Как правило, все таймеры можно объединить в heap (по-русски это вроде «пирамидой» называют). Однако, если таймерами управляет приложение, оно может объединить равноинтервальные таймеры в связанный список, привязанный к единственному элементу heap-а. В итоге rearm таймера будет иметь сложность O(1) вместо логарифмических вставки/удаления в heap. Именно поэтому я весьма скептически отношусь к помещению десятков тысяч таймеров в kqueue.
>Меня вот напрягло что запись+чтение могут придти разом, и udata для них никак не разделяется, этот код я так и не отладил, оставив рабочим вариантом когда один описатель — один тип событий.
Хранить в udata файловый дескриптор, а в userspace к файловому дескриптору привешивать цепочки watcher'ов, как это сделано в libev
>Кстати, sendfile() в линухе тоже весь такой обрезанный: не умеет данные до/после файла из буферов посылать
Но зачем? TCP_CORK + send/writev. Зачем плодить лишние сущности которые делают то же, что уже существующие? Цена syscall-а не такая высокая, как это многим кажется.
В современном ядре Linux epoll обладает практически всеми фичами kqueue (за исключением, пожалуй EVFILT_PROC). Конечно, иногда это происходит ценой написания большего количества кода, но результат получается весьма достойным.
Кстати, использование timerfd для таймеров говорит о том, что не каждый дурак способен способен реализовать таймеры эффективно: в реальных приложениях, как правило, нужны таймеры, срабатывающие через равные промежутки времени, что можно сделать за O(1) в отличие от бездумного использования heap'ов для всего и вся.
>но вот отдачи много: 2-16 мегабит в одно соединение. И куча таких вот соединение, «проксирование» IPTV потоков один-к-многим
Я абсолютно не сведущ в FreeBSD-специфичных API, но как раз для этого в Linux завезли: a) splice (-30% cpu load при проксировании «один к одному») б) vmsplice (для отдачи кучи мегабит из одного соединения, для мультиплексирования) в) tee (для мультиплексирования «с трюкачествами»)
— до тех пор, пока хватает производительности одного ядра
— до тех пор, пока оперативной памяти хватает для хранения данных
Ну и при сборке статистики нужно иметь в виду, что ввиду однопоточности сервера, обработка данных прямо внутри сервера будет блокировать его работу (придется время от времени звать box.fiber.sleep(0), что может привнекти некоторые нежелательные эффекты — до сих пор не уверен, что будет с итератором, ссылающимся на tuple, который был удалён во время такого вот sleep-а).
Как по мне, статистику в тарантуле удобней агрегировать (можно еще WAL отключить), а работать с результатом все-таки удобнее в реляционной СУБД, где для join'ов не требуется программировать.
В C++ есть нюансы, называемые «перегрузка операторов», где может встретиться вызов виртуальной функции, что требует валидного объекта для чтения vmt. Поэтому в плюсах &objptr->field действительно в общем случае UB. В C же отсутствие UB в таких случаях гарантировано стандартом.
Большая ошибка полагать, что C — это как C++ (и делать на основании этого выводы), только без классов, оверлоадинга и перегрузки операторов. Это разные языки, но с похожим синтаксисом.
Однако я цитирую стандарт C и linux kernel, фрагмент кода которого приводится, написан на языке C, по стандарту которого UB нет.
Хочу еще раз заметить, что все ваши рассуждения сводятся к «объект не может находится по адресу NULL», чего в стандарте явно не написано (см ваш перевод и оригинальный текст, которые я привел).
>перевешивают мнение таинственного dimoclus без единой публикации
Будьте любезны не скатываться на личности и уж тем более не приводить число публикаций на хабре в качестве объективного критерия компетентности.
В плюсах для не POD-типов есть нюасны, но стандарт плюсов — это совсем другая история.
Приведенная вами цитата
в Разделе 6.3.2.3 «Указатели» сказано следующее:
Если константа нулевого указателя приводится к типу указателей, то результирующий указатель, называемый нулевым, гарантированно будет не равен указателю на любой объект или функцию.
рекомендуется к повторному прочтению на языке оригинала:
If a null pointer constant is converted to a
pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal
to a pointer to any object or function.
Это означает, что any_valid_object_or_function_pointer != NULL всегда истинно.
Трактовка «нулевой указатель не указывает на объект, поэтому к его полю нельзя обратиться даже для вычисления адреса» смахивает на подмену понятий.
Вообще говоря, давайте вместе почитаем вот это (6.3.2.1 Lvalues, arrays, and function designators, п 2):
Except when it is the operand of the sizeof operator, the _Alignof operator, the
unary & operator, the ++ operator, the — operator, or the left operand of the. operator
or an assignment operator, an lvalue that does not have array type is converted to the
value stored in the designated object (and is no longer an lvalue); this is called lvalue
conversion.
Я долго думал, а потом прочитал это как
Кроме случаев, когда lvalue является аргументом операторов sizeof/alignof/унарного &/инкремента/декремента или левой частью оператора «.» или присваивания, lvalue, не являющееся массивом, преобразуется к значению, хранящемуся в означенном объекте.
Это по факту говорит нам, что чтения значения из lvalue при взятии от него адреса не происходит (а также sizeof(podh->line6), _Alignof(podh->line6)) => нет никакого разыменования => нет UB.
Читаем стандарт, нам понадобятся два пункта:
6.2.5 Types
A structure type describes a sequentially allocated nonempty set of member objects
6.5.3.2 Address and indirection operators
The unary & operator yields the address of its operand. If the operand has type ‘‘type’’,
the result has type ‘‘pointer to type’’. If the operand is the result of a unary * operator,
neither that operator nor the & operator is evaluated and the result is as if both were
omitted.
Ну а дальше начинаем толковать стандарт:
&podh->line6
/*1*/ = &(*podh).line6
/*2*/ = &(*(struct usb_line6*)((char*)podh + offsetof(struct usb_line6_podhd, line6)))
/*3*/ = (struct usb_line6*)((char*)podh + offsetof(struct usb_line6_podhd, line6))
Первый переход просто «по определению», второй — потому что структуры состоят из «последовательно расположенных непустых полей», ну а (3) даже специально прокомментирован в стандарте (страница 89, сноска 102 внизу страницы):
Thus, &*E is equivalent to E (even if E is a null pointer)
Где здесь UB?
Писать, уж простите, кучу говнокода, сваливая в кучу boost::tuple, boost::variant, std::map<std::string, std::vector<std::set<..>>>, уповая на силу аббревиатур PGO и LTO ни в коем случае нельзя.
P. S. навеяно непреодолимой тягой немалого количества C++-программистов приёмам из однострочников на perl/python/ruby (посчитать количество запятых в строке? Легко: string.split.size() и т. п.)
Никогда не пойму 10 типов людей: тех, кто парсит html регэкспами и тех, кто регулярками рефакторит.
Благодаря clang есть свет в конце тоннеля: github.com/bbchung/clighter помимо семантической подсветки умеет семантическое преобразование. К сожалению, пока работает не всегда корректно + чтобы переименовать сивол во всем проекте, нужно открыть все требуемые файлы. Но есть надежда, что дальше будет лучше.
А как же бинарная совместимость (собственноручно написанных) нативных расширений? Подобные проблемы вылезут в виде segmentation fault черте где, а не в виде сообщения интерпретатора о синтаксической ошибке, так что не бекпортировать такие вещи вполне разумное решение.
printf("%.2f\n", count * 100.0 / total);vs
std::cout << std::setprecision(2) << std::fixed << count * 100.0 / total << std::endl+ во времена g++ 3.3-4.0 в ostringstream была утечка памяти — с тех пор отношусь к ним с большой подозрительностью
А еще не помешало бы научиться читать и усваивать прочитанное: русским по белому было написано, что рефакторинг и навигация в IDE (пока) лучше.
Это сложно объяснить тому, для кого «модальное редактирование», имеет два состояния: бибикать после нажатия и все портить после .
vim — единственный на сегодня редактор, делающий упор на модальное редактирование. Современные IDE очень далеко шагнули в плане рефакторинга, навигации, дополнения кода — без всего этого они просто notepad.exe, а модальный режим там реализован убого и, скорее, «для галочки». Эти notepad'ные кишки постоянно вылезают в самое неподходящее время: в коде символ «some_long_function_name», а нужно сделать из нее «some_not_so_short_name»? Жмем «f_lc2t_not_so_short», чтобы перейти к началу «long», а затем удалить все до «_» перед «name» понадобилось всего три команды:
Когда начинаешь воспринимать редактирование не как «удалить 20 символов», а «удалить три следующих слова» или «очистить до «)», все становится значительно быстрее и, главное, ошибок становится меньше.
Что в данном случае подразумевается под «отладкой»? Пошаговая трассировка в отладчике — да, это может быть затруднительно, если макрос сплошь состоит из вызовов функций. А вот в плане отладки «во что это экспандится» макросы на много голов выше шаблонов: начиная от gcc -E и заканчивая отладкой макроэкспанда в gdb.
P. S. только слепые рабы Саттера и Александреску боятся макросов, нормальные разработчики используют все доступные средства для повышения выразительности и читаемости кода.
kill(getpid(), 9)или
*(int*)NULL = 42или что-то более изящное?
Я в некоторых проектах raise(SIGTRAP) использую, мои исходники могут заблокировать как «безнравственные»?
P. S. судя по всему «песочница» — это heap (http://en.wikipedia.org/wiki/Memory_management#HEAP)?
P.P.S. talloc.samba.org
/me вспоминает пальцы Линуса, его опусы про gcc-4.9 и многое другое.
А не путаете ли вы часом англоязычныую опенсорсную среду с платной поддержкой какого-нибудь RedHat'а, где специально обученные люди ни в коем случае не будут называть недалекого клиента так, как он того заслуживает?