Hacker News Digest

Автор экспериментирует с созданием простого брокера сообщений, используя только два UNIX сигнала вместо сложных систем вроде Kafka. Он объясняет, что сигналы обычно применяются для управления процессами, но предлагает использовать их для обмена сообщениями. Автор рассматривает различные формы IPC в UNIX, включая каналы, сокеты и файлы, а затем фокусируется на сигналах SIGUSR1 и SIGUSR2, которые являются пользовательскими и могут использоваться для собственных целей.

Основная идея заключается в представлении сообщений как последовательности битов, где каждый бит кодируется соответствующим сигналом (0 - один сигнал, 1 - другой). Это позволяет передавать данные между процессами, используя минимальные системные ресурсы. Автор демонстрирует, как можно "взломать" стандартное поведение сигналов для создания эффективной системы обмена сообщениями, опираясь на двоичное представление данных и возможность перехвата сигналов в коде на Ruby.

• Обсуждение показало, что статья вызвала бурную реакцию: от восторга до критики за clickbait-заголовок и «техническую» неточность.
• Комментаторы подчеркнули, что UNIX-сигналы не предназначены для передачи данных, не гарантируют очередность и могут терять сигналы при конкурентном доступе.
• Было отмечено, что вместо сигналов можно использовать уже готовые механизмы, такие как POSIX message queues.
• Некоторые отметили, что статья может быть интересна как учебный материал, но не как руководство к действию.
• В итоге, обсуждение показало, что читатели ожидают более честных и точных заголовков и отсутствия сенсационализма, даже в контексте развлекательных экспериментов.

Остановка потоков Linux требует аккуратного подхода, особенно при работе с низкоуровневыми потоками, созданными через pthread_create или std::thread. В отличие от запуска, корректное завершение потоков позволяет выполнить очистку ресурсов — освобождение памяти, блокировок, сброс логов. Идеального универсального решения не существует, но есть несколько подходов.

Простой метод — организация квази-активного ожидания в каждом потоке с проверкой флага остановки. Когда нужно завершить поток, флаг устанавливается в true, после чего вызывается pthread_join. Цикл не должен быть полностью неблокирующим, но должен завершаться за разумное время. Для потоков, блокирующихся на системных вызовах, используются сигналы для прерывания выполнения. Важно, что даже с этим подходом нужно учитывать обработку сигналов для корректной работы с буферизированным выводом.

• Проблема заключается в том, что POSIX не предоставляет безопасного механизма для остановки потока, и это приводит к тому, что разработчики вынуждены полагаться на pthread_cancel, который небезопасен и может привести к утечкам ресурсов или повреждению состояния.
• Попытки использовать SIGUSR1 и signalfd для обработки сигналов в пространстве пользователя не решают проблему, потому что большинство библиотек не ожидают, что их вызовы будут прерваны, и это может привести к повреждению состояния.
• Вместо этого, вместо попыток остановить поток, который может быть в любой точке, лучше структурировать код так, чтобы он мог реагировать на сигнал остановки, или использовать модель, где потоки не блокируются на системных вызовах, а вместо этого используют асинхронные вызовы и ожидают на poll/select/epoll/io_uring.
• Некоторые комментаторы отмечают, что в Linux существует io_uring, который позволяет прервать системный вызов, и что это может быть использовано для реализации остановки потока, но это не решает проблему, что не все вызовы могут быть прерваны таким образом.
• В конечном счёте, вместо попыток убить поток, который может быть в любой точке, лучше писать код так, чтобы он был отзывчив к сигналу остановки, и использовать модели, где потоки не блокируются на системных вызовах, а вместо этого используют асинхронные вызовы и ожидают на poll/select/epoll/io_uring.

Appreciating that not everyone tries to optimise for LLMs and we are still doing things like this. If you're looking at HN alone, it sometimes feels like the hype could drown out everything else. Retina-inspired video recognition using light. Cool. May be a visual cortex next yea