У меня многопоточное приложение на С++, работающее в фоновом режиме. Мне нужно корректно закрыть кучу сокетов и соединение к БД при получении SIGINT. Как молжно из обработчика сигнала сообщить другому потоку о необходимости завершения ? Судя по стандарту, трогать можно только sig_atomic_t, да и то она не thread-safe. Как быть ? Для справки: используется boost и tntnet.
И вопль души: что за идиотский механизм эти сигналы ? Зачем нужен обработчик в котором ничего нельзя делать ?
А>У меня многопоточное приложение на С++, работающее в фоновом режиме. Мне нужно корректно закрыть кучу сокетов и соединение к БД при получении SIGINT. Как молжно из обработчика сигнала сообщить другому потоку о необходимости завершения ? Судя по стандарту, трогать можно только sig_atomic_t, да и то она не thread-safe. Как быть ? Для справки: используется boost и tntnet. А>И вопль души: что за идиотский механизм эти сигналы ? Зачем нужен обработчик в котором ничего нельзя делать ?
Сигналы можно 'маскировать' при помощи sigprocmask + например существуют pselect/ppoll, которые позволяют управлять возможностью прихода сигнала. sigaction позволяет блокировать приход сигналов во время работы хэндлера + имеет прочие плюшки. Все это позволяет организовать вполне нормальную синхронизацию. Просто непривычно.
Как много веселых ребят, и все делают велосипед...
Re[2]: Корректно завершить процесс по ^C
От:
Аноним
Дата:
04.08.14 12:26
Оценка:
Здравствуйте, ononim, Вы писали:
O>Сигналы можно 'маскировать' при помощи sigprocmask + например существуют pselect/ppoll, которые позволяют управлять возможностью прихода сигнала. sigaction позволяет блокировать приход сигналов во время работы хэндлера + имеет прочие плюшки. Все это позволяет организовать вполне нормальную синхронизацию. Просто непривычно.
pselect/ppoll там где-то внури буста, я ими не управляю. Мне было бы достаточно тупо установить флаг завершения для главного пототка, и то я не знаю как это сделать на 100% надёжно.
O>>Сигналы можно 'маскировать' при помощи sigprocmask + например существуют pselect/ppoll, которые позволяют управлять возможностью прихода сигнала. sigaction позволяет блокировать приход сигналов во время работы хэндлера + имеет прочие плюшки. Все это позволяет организовать вполне нормальную синхронизацию. Просто непривычно. А>pselect/ppoll там где-то внури буста, я ими не управляю. Мне было бы достаточно тупо установить флаг завершения для главного пототка, и то я не знаю как это сделать на 100% надёжно.
Ну если оно там внутри буста то логично бы изучить то, что буст предлагает взамен. Но я этим не пользовался, так что на этом умываю руки.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Аноним, Вы писали:
А>pselect/ppoll там где-то внури буста, я ими не управляю. Мне было бы достаточно тупо установить флаг завершения для главного пототка, и то я не знаю как это сделать на 100% надёжно.
А>У меня многопоточное приложение на С++, работающее в фоновом режиме. Мне нужно корректно закрыть кучу сокетов и соединение к БД при получении SIGINT. Как молжно из обработчика сигнала сообщить другому потоку о необходимости завершения ? Судя по стандарту, трогать можно только sig_atomic_t, да и то она не thread-safe. Как быть ? Для справки: используется boost и tntnet.
Здравствуйте, Аноним, Вы писали:
А>У меня многопоточное приложение на С++, работающее в фоновом режиме. Мне нужно корректно закрыть кучу сокетов и соединение к БД при получении SIGINT. Как молжно из обработчика сигнала сообщить другому потоку о необходимости завершения ? Судя по стандарту, трогать можно только sig_atomic_t, да и то она не thread-safe. Как быть ? Для справки: используется boost и tntnet.
Можно по старомодному: записать из сигнала байтик в заранее открытый для этой цели pipe, а другой конец мониторить через poll/select/и т.п., и когда байтик придет, спокойно сделать все, что надо.
Можно по новомодному: man signalfd
А>И вопль души: что за идиотский механизм эти сигналы ? Зачем нужен обработчик в котором ничего нельзя делать ?