[superdetka 0]

Зависит от конкретной реализации. Наверное, там же, где вызывается pthread_cancel.

 

Просто тогда pthread_cancel может прервать вызов библиотеки в середине. Нет гаранитии 100 %, что вызов не меняет какие структуры , какие будут использоваться при освобождении. Вдруг cancel прервет как раз в этом момент, и при lib::free() приложение рухнет.

[firew0rker 0]

Просто тогда pthread_cancel может прервать вызов библиотеки в середине. Нет гаранитии 100 %, что вызов не меняет какие структуры , какие будут использоваться при освобождении. Вдруг cancel прервет как раз в этом момент, и при lib::free() приложение рухнет.

Если есть исходники этой библиотеки и возможность править их, то проблемы решаемы. Например, когда освобождается ресурс, обнулять указатель на него. После прерывания потока проверять указатели и не делать free тем которые ==NULL.

А нет - тогда ничего не поделаешь. Разве что намеренно не делать free и пусть висит в памяти. Если не очень много занимает - фиг с ним.

[kolobok0 0]

...Здесь вы сказали, что код дочернего потока делать не блокируемым это не вариант. Дальше вы пишите....

 

 

простите, только сейчас зашёл снова сюда... :(

 

моя фраза:

 

"Вроде как напрашивается только одно решение: делать код потока неблокируемым.

будет всё левак. самое грамотное - в сторонней библиотеке должна быть функция старта-останова стороннего потока. всё остальное - хождение по тонкому льду. шаг влево или вправо (не обязательно вы и не обязательно в ближайшем будущем) и кирдык всей конструкции."

 

эээээээээээээээ, простите где здесь "код дочернего потока делать не блокируемым это не вариант" ???

 

давайте я ышо раз повторюсь, можно? :)

дочерний поток _не_ блокируется. т.е. он работает постоянно, пока не получит шутдаун либо другое событие(зависит от функционала).

рядом, в библиотеке реализующей отдельный поток, есть функции старта и стопа. которые знают как просигнализировать порождённому потоку и как он просигнализирует об успешном окончании своей работы паренту - т.е. при таком взаимодействии явно будут синхронные фазы взаимодействия двух ниток: парента и чайлда.

 

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

 

дальше...

 

...То есть вы предложили вариант, который отвергли в предыдущем сообщении....

 

простите но в

 

"Для обеспечения постоянного мониторинга связи парент-чайлд....(и далее)"

 

была попытка озвучить пример внутреннего устройства чайлдового потока. где я, что-то (с ваших слов) "отвергал" - вообще не понятно. потому, что во фразе

 

"т.е. делать останов _не_ своей ветки = есть зло......(и далее)"

 

говорилось совсем о другом. что не стоит прерывать работу чайлдовой нитки _не_официально_ для неё. Т.е. не сигнализируя ей об останове терминировать её, либо выдать через переферию которая она юзает не ликвидное значение и т.п. вещи.

 

эти два сообщения вообще то о разном были... как не надо и как возможно - на примере.

 

ясность появилась на горизонте или туман сгущается?

Изменено 2 августа, 2013 пользователем kolobok0

[superdetka 0]

я пожалуй вежливо промолчу)