Hacker News Digest

Остановка потоков 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.

• История: от pre-fork до epoll — каждый шаг уменьшал сисколлы, но они всё ещё оставались узким местом.
• io_uring — кольцевые очереди в памяти: сервер пишет команды, ядро асинхронно их выполняет и кладёт результат обратно. При высокой нагрузке strace не покажет ни одного сисколла.
• 1 поток = 1 ядро без разделяемых структур; память берётся только из локального NUMA-узла.
• Память: заранее выделяем фиксированный буфер на соединение — без brk/mmap, без фрагментации.
• kTLS — после рукопожатия шифрование переходит в ядро. Плюсы:
  1. Работает sendfile, данные не копируются в userspace.
  2. Возможно аппаратное ускорение NIC.

• io_uring даёт «zero-syscall» при высокой нагрузке, но требует ручного управления памятью: безопасность не обеспечивается ни borrow checker, ни runtime.
• На большинстве облачных платформ io_uring выключен по умолчанию, поэтому остаётся нишевым.
• Автор статьи сначала чистит код, а потом будет мерить производительность — что вызвало одобрение читателей.
• Обсуждаются альтернативы: epoll, kTLS, DPDK, eBPF, а также споры «один поток на ядро» vs oversubscription.
• Некоторые считают, что сложность io_uring и async Rust — цена за неспособность ОС ускорить syscalls без нарушения обратной совместимости.