Являются ли сигналы IPC

Являются ли сигналы IPC (Inter-Process Communication)?

Да, сигналы (signals) в Unix/Linux являются формой IPC, но это очень специфичная и ограниченная форма. Давайте разберемся подробно.

Определение сигналов

Сигнал — это асинхронное уведомление, отправляемое операционной системой процессу (или потоку) о каком-либо событии. Это форма межпроцессного взаимодействия, где ОС посредничает.

// Простейший пример сигнала
#include <signal.h>
#include <iostream>
#include <unistd.h>

void handler(int sig) {
    std::cout << "Получил сигнал: " << sig << std::endl;
}

int main() {
    signal(SIGUSR1, handler);  // Зарегистрируем обработчик
    
    std::cout << "Мой PID: " << getpid() << std::endl;
    
    while(true) {
        sleep(1);
        // Из другого процесса:
        // $ kill -SIGUSR1 12345
    }
    return 0;
}

Сигналы как IPC

Да, сигналы — это IPC потому что:

1. Взаимодействие между процессами — один процесс может отправить сигнал другому

   kill -SIGUSR1 12345  # Отправляем сигнал процессу с PID 12345
   

2. Через ОС — ОС медиирует передачу

   Процесс A --[kill()]--> ОС --[signal]--> Процесс B
   

3. Уведомление об событии — это форма асинхронной коммуникации

Но это ОЧЕНЬ ограниченный IPC

Главные ограничения сигналов:

1. Нет передачи данных (только номер сигнала)

// Можем отправить только сигнал
kill(pid, SIGUSR1);  // Отправили SIGUSR1

// Но НЕ можем передать данные
kill(pid, SIGUSR1, some_data);  // НЕВОЗМОЖНО!

// С real-time сигналами можно передать одно целое число:
kill(pid, SIGRTMIN + 5);  // queue 5

// Но это ограничено и сложно
union sigval value;
value.sival_int = 42;
sigqueue(pid, SIGUSR1, value);

2. Потеря данных при быстрых сигналах

// На обычных сигналах (не real-time):
// Если отправить SIGUSR1 10 раз подряд,
// обработчик вызовется только ОДИН раз!

void handler(int sig) {
    std::cout << "Обработано" << std::endl;
}

int main() {
    signal(SIGUSR1, handler);
    
    // Отправляем сигнал 10 раз
    for(int i = 0; i < 10; i++) {
        kill(getpid(), SIGUSR1);
    }
    // Вывод: "Обработано" только ОДИН раз!
}

3. Асинхронность и недетерминизм

int global_data = 0;

void signal_handler(int sig) {
    global_data++;  // ОПАСНО! Может быть прерыва в любой момент
}

int main() {
    signal(SIGUSR1, signal_handler);
    
    for(int i = 0; i < 100; i++) {
        global_data++;  // Race condition если придёт сигнал!
    }
    
    // global_data может быть любой от 100 до 200!
}

Безопасный вариант:

#include <atomic>
std::atomic<int> global_data = 0;

void signal_handler(int sig) {
    global_data++;  // Atomically safe
}

4. Ограниченный набор операций в обработчике

void unsafe_handler(int sig) {
    printf("Signal received");  // ОПАСНО! printf не async-safe
    malloc(100);              // ОПАСНО! malloc не async-safe
    std::cout << "Hello";     // ОПАСНО! cout не async-safe
    pthread_mutex_lock(&m);   // ОПАСНО!
}

void safe_handler(int sig) {
    // Только async-safe функции!
    write(STDOUT_FILENO, "Signal\n", 7);  // OK: write
    flag = 1;                             // OK: simple assignment
    signal(SIGUSR1, signal_handler);      // OK: signal
}

Сравнение с другими IPC механизмами

Реальное использование сигналов

Пример 1: Graceful shutdown

#include <signal.h>
#include <atomic>
#include <iostream>
#include <thread>
#include <chrono>

std::atomic<bool> should_exit(false);

void signal_handler(int sig) {
    should_exit = true;  // Флаг завершения
}

int main() {
    signal(SIGTERM, signal_handler);
    signal(SIGINT, signal_handler);
    
    std::cout << "Server running, PID: " << getpid() << std::endl;
    
    while(!should_exit) {
        // Работа сервера
        std::this_thread::sleep_for(std::chrono::seconds(1));
        std::cout << "Processing..." << std::endl;
    }
    
    std::cout << "Shutting down gracefully..." << std::endl;
    // Cleanup
    return 0;
}

// Использование:
// $ ./server &
// Server running, PID: 12345
// $ kill -SIGTERM 12345
// Shutting down gracefully...

Пример 2: Родитель отправляет сигнал дочернему процессу

#include <unistd.h>
#include <signal.h>
#include <iostream>
#include <sys/wait.h>

int main() {
    pid_t pid = fork();
    
    if(pid == 0) {  // Дочерний процесс
        signal(SIGUSR1, [](int){});
        std::cout << "Child: waiting for signal..." << std::endl;
        sleep(10);
        std::cout << "Child: done" << std::endl;
        exit(0);
    } else {  // Родительский процесс
        sleep(2);  // Ждём 2 секунды
        std::cout << "Parent: sending SIGUSR1 to child..." << std::endl;
        kill(pid, SIGUSR1);
        
        int status;
        waitpid(pid, &status, 0);
        std::cout << "Parent: child terminated" << std::endl;
    }
    return 0;
}

Пример 3: Обработка SIGCHLD при завершении child процесса

#include <signal.h>
#include <unistd.h>
#include <sys/wait.h>
#include <iostream>

void handle_sigchld(int sig) {
    // Ребячество: дочерний процесс завершился
    pid_t pid;
    int status;
    
    while((pid = waitpid(-1, &status, WNOHANG)) > 0) {
        if(WIFEXITED(status)) {
            std::cout << "Child " << pid << " exited with code " 
                      << WEXITSTATUS(status) << std::endl;
        }
    }
}

int main() {
    signal(SIGCHLD, handle_sigchld);
    
    pid_t pid = fork();
    if(pid == 0) {
        // Дочерний процесс
        sleep(2);
        exit(42);
    }
    
    // Родительский процесс продолжает работу
    for(int i = 0; i < 5; i++) {
        std::cout << "Parent working..." << std::endl;
        sleep(1);
    }
    return 0;
}

Почему не использовать сигналы для серьёзного IPC?

Проблемы:

1. Потеря данных — сигналы могут теряться
2. Нет гарантий — асинхронность вызывает race conditions
3. Сложно отлаживать — недетерминированное поведение
4. Ограничено — только уведомления, не передача данных
5. Потокобезопасность — nightamre в многопоточных программах

Лучшие альтернативы для реального IPC

// Вместо сигналов используй:

// 1. Message Queues (POSIX)
mq_send(mqd, message, size, priority);
mq_receive(mqd, message, size, &priority);

// 2. Pipes
int fd[2];
pipe(fd);
write(fd[1], data, size);
read(fd[0], data, size);

// 3. Unix Domain Sockets
socket(AF_UNIX, SOCK_STREAM, 0);

// 4. Shared Memory
int shmid = shmget(IPC_PRIVATE, size, IPC_CREAT);
void* ptr = shmat(shmid, nullptr, 0);

// 5. Semaphores (для синхронизации)
sem_t sem;
sem_init(&sem, 0, 1);
sem_wait(&sem);
sem_post(&sem);

Итог

Сигналы являются IPC, но:

• Это IPC первого поколения — очень примитивное

• Используй только для:

  • Graceful shutdown (SIGTERM, SIGINT)
  • Уведомления о системных событиях (SIGCHLD, SIGALRM)
  • Простые флаги состояния

• НЕ используй для:

  • Передачи сложных данных
  • Критичных по надёжности систем
  • Многопоточных приложений (используй condition variables вместо сигналов)
  • Высоконагруженных систем

Modern подход: в многопоточных приложениях используй condition variables, в распределённых — message queues, в критичных по производительности — shared memory.

Сигналы остались в Unix как исторический артефакт, но для современной разработки существуют лучшие инструменты.