Кто использует сигналы POSIX в реальном времени и почему?

Question

Я не переворачиваюсь, я действительно не понимаю. Я просто прочитал целую кучу материалов о них, и я не могу понять вариант использования. Я не говорю о том, чтобы говорить об API, для которого преимущества над такими вещами, как signal (), достаточно очевидны. Скорее всего, сигналы RT предназначены для генерирования пространства пользователя, но для чего? Кажется, единственное использование - это примитивный IPC, но все указывает на то, что они являются паршивой формой IPC (например, неловкая, ограниченная информация, не особенно эффективная и т. Д.).

Так где и как они используются?

Answer 1

Прежде всего, обратите внимание, что ответ Бена правильный. Насколько я могу судить, вся цель сигналов реального времени в POSIX - это механизм доставки в реальном времени для AIO, уведомлений об очереди сообщений, истечения таймера и сигналов, определяемых приложением (как внутренних, так и межпроцессных).

С учетом вышесказанного, сигналы в целом - это действительно плохой способ сделать что-то:

• Обработчики сигналов являются асинхронными, и если вы не гарантируете, что они не прерывают небезопасную асинхронную функцию, они могут использовать только безопасные для асинхронных сигналов функции, которые действительно наносят вред тому, что они могут делать.
• Обработчики сигналов находятся в глобальном состоянии. Библиотека не может использовать сигналы без договора с вызывающей программой относительно того, какие сигналы ей разрешено использовать, разрешено ли их прерывание системным вызовом и т. Д. И вообще, глобальное состояние - это просто A Bad Thing .
• Если вы используете sigwait (или расширение Linux signalfd), а не обработчики сигналов для обработки сигналов, они ничем не лучше других механизмов IPC / уведомлений и все еще потенциально хуже.

Асинхронный ввод-вывод гораздо лучше достигается путем игнорирования неправильно разработанного API-интерфейса POSIX и простого создания потока для выполнения нормального блокирования ввода-вывода и вызова pthread_cond_signal или sem_post после завершения операции. Или, если вы можете себе позволить небольшую потерю производительности, вы можете даже переслать только что прочитанные данные себе по каналу или паре сокетов и сделать так, чтобы основной поток обрабатывал обычные файлы с асинхронным чтением с select или poll так же, как вы бы розетки / трубы / ттыс.

Answer 2

Асинхронный ввод / вывод.

Сигналы в реальном времени - это механизм для ядра, информирующий вашу систему о завершении операции ввода / вывода.

struct aiocbустанавливает связь между запросом асинхронного ввода-вывода и номером сигнала.

Answer 3

Это старый вопрос, но все же.

Потоки POSIX в Linux в glibc (NPTL) реализованы с использованием двух сигналов реального времени.Они скрыты от пользователя (путем настройки констант числа мин / макс).Все события, при которых вызов библиотеки должен распространяться на все потоки (например, setuid), выполняются через них: вызывающий поток отправляет сигнал всем потокам, чтобы применить изменение, ожидает подтверждения и продолжает.

Answer 4

Существуют и другие причины использовать сигналы в реальном времени. У меня есть приложение, которое взаимодействует с различными внешними устройствами и делает это с помощью комбинации средств (последовательный порт IO, даже прямая адресация некоторых карт старше, чем большинство знакомых вам людей). По определению, это приложение «реального времени» - оно взаимодействует с реальным миром в реальном времени, а не в «компьютерном времени».

Многое из того, что он делает, находится в процессе демона, который находится в основном цикле: обработка события, чтение информации, запись результатов в последовательные порты, сохранение данных в базе данных и т. Д., А затем циклическое повторение для другого события , Другие процессы на машине (пользовательские процессы) считывают информацию из БД, отображают ее и т. Д. Пользователь в этих других процессах может отправлять различные сигналы демону, чтобы предупредить его о различных условиях: остановка, изменение входных данных и так далее. Например, пользовательский процесс отправляет сигнал «стоп», подпрограмма обработчика сигналов демона имеет около 2 строк кода, устанавливающих переменную flag. Когда у демона появляется шанс, и это удобно, он останавливается. Код «прерывания» очень прост, быстр и неинвазивен. Но он служит цели, не требует сложных структур IPC и работает просто отлично.

Итак, да, есть причины для этих сигналов. В приложениях реального времени. При правильном обращении они работают просто отлично, спасибо.