Ctrl + C: это убивает потоки вместе с основным процессом? - PullRequest
2 голосов
/ 29 апреля 2011

Во время работы потоковой программы и многократного уничтожения основной программы с помощью Ctrl + C я вижу неожиданные результаты в программе при втором запуске.Однако, если я позволю программе работать и добровольно завершить работу, проблем не будет.

Итак, я сомневаюсь, Ctrl + C, убивает ли потоки также вместе с основным процессом?заранее.

Ответы [ 3 ]

3 голосов
/ 29 апреля 2011

В многопоточном программировании сигналы доставляются в один поток (обычно непредсказуемо выбираемый среди потоков, у которых этот конкретный сигнал не заблокирован). Однако это не означает , что сигнал, действие по умолчанию которого состоит в уничтожении процесса, завершает только один поток. На самом деле, нет способа убить один поток, не уничтожив весь процесс.

Пока вы оставляете SIGINT с действием по умолчанию, завершающим процесс, он будет делать это, пока хотя бы один поток оставляет SIGINT разблокированным. Не имеет значения, в каком потоке он разблокирован, пока хотя бы один из них делает это, поэтому код библиотеки, создающий потоки за спиной приложения, должен всегда блокировать все сигналы перед вызовом pthread_create и восстанавливать маску сигналов в вызывающем потоке впоследствии.

2 голосов
/ 29 апреля 2011

Ну, единственное, что делает Ctrl + C, это отправляет SIGINT в один поток в процессе, который не маскирует сигнал. Сигналы могут обрабатываться или игнорироваться.

Если программа обрабатывает , обрабатывает Ctrl+C, обычное поведение - самоотключение, но, опять же, оно может использоваться для чего-либо еще.

В вашем случае SIGINT принимается одним потоком, который, вероятно, убивает себя, но не убивает других.

1 голос
/ 30 апреля 2011

В Linux 2.6 с использованием потоков NPTL: я предполагаю, что процесс использует обработчик сигналов по умолчанию или вызывает в нем функцию exit (): Да, это так. Вызов exit () из библиотеки C отображается на системный вызов exit_group, который немедленно завершает работу всех потоков; обработчик сигнала по умолчанию вызывает это или что-то подобное.

В Linux 2.4 с использованием Linuxthreads (или с использованием 2.6, если ваше приложение все еще использует Linuxthreads по какой-то странной причине): необязательно.

Библиотека Linuxthreads реализует потоки с помощью clone (), создавая новый процесс, который делится своим адресным пространством с родителем. Это не обязательно умирает, когда умирает родитель. Чтобы это исправить, существует «главный поток», который создает pthreads. Этот главный поток выполняет различные действия, одна из них - попытаться убедиться, что все потоки будут уничтожены при выходе из процесса (по любой причине).

  1. Это не обязательно удастся
  2. Если это успешно, это не обязательно немедленно, особенно если есть большое количество потоков.

Так что, если вы используете Linuxthreads, возможно, нет.

Другие потоки могут не завершиться немедленно или вообще не работать.

Однако, независимо от того, какую библиотеку потоков вы используете, разветвленные дочерние процессы будут продолжаться (они могут получить сигнал, если они все еще находятся в той же группе процессов, но могут свободно его игнорировать)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...