форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

"pthread_cancel/pthread_join"
Сообщение от Milana (ok) on 08-Июл-05, 14:10  (MSK)
Всем здравствуйте! Помогите пожалуйста разобраться с таким вопросом: в контейнере типа list<...*> у меня храняться указатели на объекты, в которых есть public data member pthread_t. В обработчике сигнала sigterm основного потока рассылаю всем нитям нечто на подобии for_each(..., ..., cancelThread ); и жду когда все завершатся- for_each( ..., ..., joinThread ); inline (cancel/join)Thread( ...* p ) { pthread_(cancel/join)( p->(поле) ); } Код не точный, но смысл сохранен. Так вот, грабли в том, что cancel корректно (судя по возвращаемым значениям) рассылается, а на первом join'е все встрявает. Если посылаешь второй такой же сигнал, cancel рассылается с кодом возврата 3, но join тогда проходит Ok. os- FreeBSD5.3,cc- gcc 3.4.2
	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "pthread_cancel/pthread_join"
Сообщение от DeadMustdie (??) on 08-Июл-05, 19:49  (MSK)
Вообще ждать завершения потоков в обработчике сигналов глубоко неправильно. Равно как и применять pthread_cancel() в программе на C++, поскольку деструкторы созданных на стеке объектов при этом не отработают. Что при использовании STL гарантирует утечки памяти. Причины описанной проблемы могут быть разные, всё сильно зависит от кода поточных функций и кода главного потока. Советую передачу команды на завершение потоков реализовать путём установки специального значения в переменную типа 'volatile int', а остановки потоков ожидать в главном потоке. Переход к нужный режим можно реализовать на основе pthread_cond_wait() & friends, условие инициировать в обработчике сигналов.
Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	2. "pthread_cancel/pthread_join"
	Сообщение от Milana (ok) on 08-Июл-05, 21:46  (MSK)
	>Вообще ждать завершения потоков в обработчике сигналов глубоко неправильно. Если не секрет, по какой причине? А то я предвижу аналогичную проблему с sighup.
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "pthread_cancel/pthread_join"
	Сообщение от DeadMustdie (??) on 08-Июл-05, 22:49  (MSK)
	>Если не секрет, по какой причине? А то я предвижу аналогичную проблему >с sighup. На код обработчика сигналов накладывается очень много ограничений. Всё время, которое поток проводит в обработчике сигналов, этот поток не может обрабатывать другие сигналы. В не совсем прямых реализациях POSIX-потоков тем самым можно вообще заблокировать всю обработку сигналов процессом, а при таком раскладе вновь поступающие сигналы вообще не будут обрабатываться. В некоторых случаях это блокирует насмерть часть функций стандартной библиотеки C. Моя обычная практика заключается в запрете обработки сигналов вообще всеми потоками и запуске дополнительного потока, содержащего циклический вызов sigwait(). По крайней мере, здесь можно гарантировать аккуратный захват и освобождение всех необходимых блокировок и, тем самым, гарантировать целостность общих для всех потоков структур данных. А в обработчике сигналов можно очутиться на середине обновления какой-либо используемой в нём структуре - после чего обычно с небес валится SIGSEGV. Причём поди пойми, из-за чего.
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "pthread_cancel/pthread_join"
	Сообщение от Vladislav Lazarenko on 09-Июл-05, 14:17  (MSK)
	>>Если не секрет, по какой причине? А то я предвижу аналогичную проблему >>с sighup. > >На код обработчика сигналов накладывается очень много ограничений. >Всё время, которое поток проводит в обработчике сигналов, этот поток >не может обрабатывать другие сигналы. В не совсем прямых реализациях >POSIX-потоков тем самым можно вообще заблокировать всю обработку >сигналов процессом, а при таком раскладе вновь поступающие сигналы >вообще не будут обрабатываться. В некоторых случаях это блокирует >насмерть часть функций стандартной библиотеки C. > >Моя обычная практика заключается в запрете обработки сигналов вообще >всеми потоками и запуске дополнительного потока, содержащего циклический >вызов sigwait(). По крайней мере, здесь можно гарантировать аккуратный >захват и освобождение всех необходимых блокировок и, тем самым, >гарантировать целостность общих для всех потоков структур данных. >А в обработчике сигналов можно очутиться на середине обновления >какой-либо используемой в нём структуре - после чего обычно с >небес валится SIGSEGV. Причём поди пойми, из-за чего. pthread_cancel - от лукавого...
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "pthread_cancel/pthread_join"
	Сообщение от Milana (ok) on 11-Июл-05, 13:09  (MSK)
	>pthread_cancel - от лукавого... А почему он так Вам ненравится? Я просто не очень хочу нагружать потоковые функции различными флагами и проверками по сути не относящимися к их основной задаче. Тогда возникает вопрос- как сообщитьь нитям, что они должны сворачивать свою деятельность. Что касается критических мест в потоках, то их можно защитить pthread_setcancelstate. А если понадобятся автоматические объекты, то их можно тоже поместить в такую секцию, которая выполнится до конца и обеспечит выполнение всех деструкторов.
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ]

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.