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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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