Minoru
09.08.2012 14:50 micropost
Век живи, век учись: почерпнул из http://juick.com/2013688 новый для себя трюк. Есть у нас некая нить, в которой крутится poll(), и нам нужно нить эту аккуратно завершать (то есть не просто pthread_cancel(), а по-человечески, с освобождением ресурсов). Раньше я бы тупо добавил таймаут в poll и проверял бы какую-то общую переменную-флаг, но теперь я умный: можно создать pipe и поместить его дескриптор в список опрашиваемых poll() ресурсов. Чтобы завершить нить, достаточно будет в этот самый пайп что-нибудь записать. Красота!
Recommended by:
@hirthwork: интересный финт ушами
and @magog
21 comment
recommend
bookmark
subscribe
а что мешает послать сигнал треду, чтобы он вышел из блокирующей функции?
почему-то похоже на глязный хак
*р
poll() может быть заблокирован. Не слать же sigkill, право?
Хотя стоп, сигналы же все равно обрабатываются, что бы там тред не делал.
Нормально, как по мне. Вот shared variable — это грязно! l29ah на bnw ( https://bnw.im/p/HLM0GH#6N2) рекомендует pthread_cleanup_push, кстати.
например потому что тред получит просто EINTR в ответ на poll() и не будет знать надо ли ему повторять вызов или завершаться? или я ничего не пони в треда и ты о каких-то других сигналах?
Хотя, можно при EINTR проверять какой-нибуь флаг...
да, при получении сигнала во время ожидания завершения syscall он прерыватся и возвращает errno == EINTR
вот да, это как-то полущ костылей с общими переменными
блокирующий вызов выйдет, если треду придёт сигнал
при EINTR всегда нужно проверять подобные флаги
Какие? Shared variable, указывающую, следует ли завершаться? :)
например
То есть ты предлагаешь написать и установить в треде signal handler, а потом ещё пробросить туда же shared variable, которую нужно не забыть поменять перед тем, как бросать сигнал? И это предлагается в качестве альтернативы созданию и пробросу пайпа с последующей записью в него любой чепухи? А не джавист ли ты часом?..
я предлагаю вешать глобальный signal handler, суть которого будет в запуске shutdown thread, который вызовет синхронный метод MyServer.shutdown(), который уже у всех своих инстансов запустят процесс остановки и при необходимости пошлют сигналы тем тредам, которые при старте зарегистрировались как «прервите меня сигналом»
> создание тредов из signal handler'а
> синхронный метод
> инстансы
> треды регистрируются как «прервите меня сигналом»
Ты отдаёшь себе отчёт в том, что твое предложение — это такой лютый-бешеный overengineering, что просто слов нет?
ты отдаёшь себе отчёт, что твоё заявление ничем не подкреплено? и это не overengineering, у меня реально может крутиться больше тысячи тредов выполняющих десяток различных задач.
Моё заявление подкреплено тем фактом, что ты для решения маленькой проблемы предлагаешь добавить костыль (shared variable, проверяемая при получении сигнала), обвешанный enterprise-level рюшечками (синхронный метод, инстансы, регистрация тредов). По этой же причине я считаю твоё решение overengineering'ом.
> у меня
Извини, я не заметил, как мы перешли от решения проблемы с завершением одного-единственного треда к твоим огромным сервисам с тысячами тредов.
извини, я как-то не заметил, что обсуждается завершение приложений состоящих из строго одной нити
Я предлагаю перейти к решению задачи в терминах barrel processor'а.
Хех, даже такие архитектуры придумывают…