Но дельта-сигма цапы не занимаются поиском того заветного и единственного решения, существующего по теореме Котельникова-Найквиста. Они что-то там аппроксимируют, что разработчикам на душу положит какое-нибудь чувство прекрасного звучания. Потом результат нужно пропускать через LFF, что прямо выходит за рамки формулировки теоремы (потому что ошибки ЦАП дают высокочастотный мусор, инвалидирующий условие), на которую ссылаются нелюбители hi-res.
Сравнивать надо в аналоговом домене, вычитая сигналы после оцифровки и фильтра нижних частот.
Под pipe trick понимают запись из обработчика сигнала в канал, при этом или основной цикл делает select(2) на чтение из другого конца канала, или (реже, как вы сказали) выделенная нитка читает из канала. Выделенная нитка неудобна тем, что ее нужно все равно интегрировать в основной событийный цикл с select/poll/epoll/kqueue.
Наскольно я помню, в линуксах есть signalfd(2), возвращающий файловый дескриптор, который можно использовать с select/epoll для синхронного оповещения о поступлении асинхронного сигнала напрямую, без создания канала.
То, что вы описали, формально правильно с точки зрения стандартов C и POSIX. Разве что, вы не упомянули atomic_signal_fence(), которая становится крайне необходима при нетривиальной работе с сигналами и современными компиляторами.
Содержательно ваша статья правильна для асинхронных сигналов. Но для них более предпочтительным подходом является sigwait(2) или в крайнем случае pipe trick. При использовании блока сигнала и sig*wait(2), обработчики не нужны, как они по сути не нужны и при использовании pipe trick (точнее, тут будет тривиальный заведомо async signal safe обработчик).
А вот для синхронных сигналов, которые доставляются синхронно как результат исключения, и именно в нитку, которая исключение сгенерировала, все существенно по другому. Во-первых, обработчику известно состояние программы, потому что известно место, где произошло исключение. Во-вторых, в обработчике обычно можно пользоваться практически всеми сервисами runtime (если только мы не говорим об исключениях вследствие разрушения состояния).
Из синхронного обработчика можно выйти не только восстановлением прерванного контекста, но и средствами типа longjmp или раскруткой стека. При этом вы не попадете в среду, где можно будет безопасно пользоваться только async-signal safe функциями, это будет нормальный контекст исполнения.
Современные типичные пользователи синхронных исключений - это всевозможные managed runtimes, которые реализуют на них барьеры для сборщиков мусора, парковку ниток, отслеживание выполнения (редких) блоков кода и тд.
Кстати, забавно, что работа с сигналами не обеспечена в Rust stdlib. Лучшее из того, что я находил, signal-hook, выглядит неубедительно.
casewise здесь никак не 'чувствительность к регистру'. Это или 'от случая к случаю', или 'специфическая проверка', но к регистру оно отношения не имеет.
Нужно же понимать, что написано. В mac-mls указаны варианты с модулем и без, на выбор. Оба сразу бессмыслица.
Давайте я вам вслух зачитаю начало мана, там слов не пожалели.
MAC_MLS(4) FreeBSD Kernel Interfaces Manual MAC_MLS(4)
NAME
mac_mls Multi-Level Security confidentiality policy
SYNOPSIS
To compile MLS into your kernel, place the following lines in your kernel
configuration file:
options MAC
options MAC_MLS
Alternately, to load the MLS module at boot time, place the following
line in your kernel configuration file:
options MAC
and in loader.conf(5):
mac_mls_load="YES"
Зачем добавлять опцию в конфиг, если вы грузите модуль? Точнее, у вас после такой манипуляции будет работать модуль, влинкованный в ядро, а тот, что загрузится лоадером, проигнорирован.
Но к слову, Infiniband первоначально предназначался и для внутреннего интерконнекта, поэтому маркетинговые описания могут быть похожими. Кроме того, и PCIe и Infiniband — это packet-switched networks, с гарантированной доставкой и низкой латентностью.
Подскажите, раз стандарт открытый и любые третьи лица могут его использовать, гда скачать текст стандарта? На сайте есть только указание 'how to join' с требованиями, прямо противоположными открытости стандарта (и membership fee).
Я бы начал с того, что обновил операционку. Такая проблема скорее похожа на ошибку сохранения/восстановления контекста FPU, а не аппаратную. Кроме того, поскольку у вас есть изолированный пример на С++, попробуйте загрузить live-CD с линуксом и проверьте на этом же железе, но с другой OS.
Но дельта-сигма цапы не занимаются поиском того заветного и единственного решения, существующего по теореме Котельникова-Найквиста. Они что-то там аппроксимируют, что разработчикам на душу положит какое-нибудь чувство прекрасного звучания. Потом результат нужно пропускать через LFF, что прямо выходит за рамки формулировки теоремы (потому что ошибки ЦАП дают высокочастотный мусор, инвалидирующий условие), на которую ссылаются нелюбители hi-res.
Сравнивать надо в аналоговом домене, вычитая сигналы после оцифровки и фильтра нижних частот.
Нет 'bsd-ного' awk, это one-true-awk от собственно авторов языка. Если нужен gawk, то его и поставьте.
это называется tmpfs, обычно монтируется в /tmp
конечно есть /dev/std{in,out,err}, как и /dev/fd/
опять-таки, поставьте bash. Только не пишите #!/bin/bash, хотя бы #!/usr/bin/env bash
Под pipe trick понимают запись из обработчика сигнала в канал, при этом или основной цикл делает select(2) на чтение из другого конца канала, или (реже, как вы сказали) выделенная нитка читает из канала. Выделенная нитка неудобна тем, что ее нужно все равно интегрировать в основной событийный цикл с select/poll/epoll/kqueue.
Наскольно я помню, в линуксах есть signalfd(2), возвращающий файловый дескриптор, который можно использовать с select/epoll для синхронного оповещения о поступлении асинхронного сигнала напрямую, без создания канала.
То, что вы описали, формально правильно с точки зрения стандартов C и POSIX. Разве что, вы не упомянули atomic_signal_fence(), которая становится крайне необходима при нетривиальной работе с сигналами и современными компиляторами.
Содержательно ваша статья правильна для асинхронных сигналов. Но для них более предпочтительным подходом является sigwait(2) или в крайнем случае pipe trick. При использовании блока сигнала и sig*wait(2), обработчики не нужны, как они по сути не нужны и при использовании pipe trick (точнее, тут будет тривиальный заведомо async signal safe обработчик).
А вот для синхронных сигналов, которые доставляются синхронно как результат исключения, и именно в нитку, которая исключение сгенерировала, все существенно по другому. Во-первых, обработчику известно состояние программы, потому что известно место, где произошло исключение. Во-вторых, в обработчике обычно можно пользоваться практически всеми сервисами runtime (если только мы не говорим об исключениях вследствие разрушения состояния).
Из синхронного обработчика можно выйти не только восстановлением прерванного контекста, но и средствами типа longjmp или раскруткой стека. При этом вы не попадете в среду, где можно будет безопасно пользоваться только async-signal safe функциями, это будет нормальный контекст исполнения.
Современные типичные пользователи синхронных исключений - это всевозможные managed runtimes, которые реализуют на них барьеры для сборщиков мусора, парковку ниток, отслеживание выполнения (редких) блоков кода и тд.
Кстати, забавно, что работа с сигналами не обеспечена в Rust stdlib. Лучшее из того, что я находил, signal-hook, выглядит неубедительно.
Давайте я вам вслух зачитаю начало мана, там слов не пожалели.
Но к слову, Infiniband первоначально предназначался и для внутреннего интерконнекта, поэтому маркетинговые описания могут быть похожими. Кроме того, и PCIe и Infiniband — это packet-switched networks, с гарантированной доставкой и низкой латентностью.