Не используйте отмену потока, если вы можете этого избежать. Есть довольно много проблем и подводных камней, с которыми нужно бороться.
Один класс проблем связан с очисткой ресурсов. Хотя POSIX определяет механизм регистрации обработчиков очистки для решения этой проблемы, требуется большая кропотливая работа, чтобы гарантировать, что все ресурсы - выделенная память, открытые файлы, мьютексы и семафоры, общее общее состояние - должным образом очищены этими средства. Для потока очень легко, скажем, не разблокировать мьютекс, который он удерживает заблокированным при его отмене, таким образом блокируя каждый поток, который впоследствии пытается безоговорочно заблокировать его.
Другой, более тонкий класс Проблемы связаны с тем, в какой момент поток может быть отменен. По умолчанию поток с ожидающим сигналом отмены будет завершен, когда он в следующий раз достигнет точки отмены или если он уже заблокирован в точке отмены. Значительное количество функций POSIX определенно являются или могут быть точками отмены, но не все.
В частности, pthread_mutex_lock()
не является точкой отмены . Таким образом, если вы отмените поток, который заблокирован в pthread_mutex_lock
, он не будет немедленно отменен. В принципе, он может успешно заблокировать мьютекс, а затем продолжить, пока не достигнет точки отмены, или он может вернуться без блокировки мьютекса (с ненулевым кодом возврата, чтобы указать характер ошибки). Любой из них может доставить вам неприятности, но первый кажется особенно готовым поставить вас в тупик. На практике pthread_mutex_lock()
задокументировано как not return EINTR
, что заставляет меня ожидать, что будет продемонстрирована первая альтернатива: запросы отмены не приведут к завершению потока, заблокированного в pthread_mutex_lock()
, без получения мьютекс и возврат.