Добрый день!

Не подскажите с реализациями завершения потоков? Как обработать такую ситуацию : дочерний поток висит на вызове блокируемой функции из third-party библиотеки. Родительский поток хочет его завершить. Как сделать? Учитывать корректное освобождение ресурсов.

Api: pthread, система: Linux

Спасибо!

Нет, я все-таки подскажу!!!
Чтобы разбудить блокированный поток, пошлите ему сигнал SIGTHR: pthread_kill(thr, SIGTHR).

Ой, простите. SIGTHR есть только в BSD. Похоже, в linux Вам поможет только pthread_cancel().

pthread_cancel() доходит до потока когда он натыкается на cancellation point и поток завершается после этой точки, можно добавить обработчики на выходе. Но если используется сторонняя библиотека и один из ее вызовов прервется на середине выполнения при cancel(), откуда знать что она не рухнет, когда в обработчике будет происходит освобождение ее ресурсов. Тоже самое с сигналом и его обработчиком. Или хорошая библиотека не должна так делать?)
В функциях может стоять if (errno == EINTR)

Ниоткуда. Поток будет немедленно снят с выполнения, никакой код после заблокировавшего вызова не будет выполнен, и занятые ресурсы останутся занятыми.

Если бы у Вас библиотека была в исходниках, я бы предложил использовать в ней poll/select. Но у Вас, как я понял, исходников нет. Не знаю, как в linux решить эту проблему.

Вы можете просто убить поток, а освободить ресурсы в том месте где убили, но для этого надо иметь явный контекст потока

а не будет ли это одно и тоже, что и освободить ресурсы в обработчиках при завершении? Явный контекст потока , вы имели ввиду, что ясно представлять код?

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

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

а есть пример какой-нибудь?

пример чего? вызов функции или параметров возвращаемых? Или потроха самой функции?

сами функции чего-то аля (без привязки к юниксу или языку).



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

где то так.
особо отмечу _синхронную_фазу_старта_и_останова_ ниток. Типичная ошибка многих программистов не дожидаться подъёма и готовности ниток. Отсюда, при высокой нагрузке (ударной) по системе - идёт дрейф привычных временных интервалов. Или по другому. Если не ожидается успешность старта и начала работы нитки - то нафига её вообще порождать?

Вы наверно невнимательно прочитали тему. Вы дали "пример" функций о реализации которых тема и заводилась. Как вы сами описали, что эти функции часть api библиотеки. Где же место пользовательскому коду здесь?) Согласен с ситауцией допустим воспроизведение видео файла lib::start("file_path"); lib::stop(); Но такой простой api почти всегда не прокатывает. Такие функции носят больше reference характер, чем использование в рабочем коде. Также не все библиотеки имеют такой реферс. Всегда приходится реализовывать их самому. Вот об этом и вопрос. О конктретной части правда, как в функции stop() реализовать корректый останов потока?

Вы не вчитывались в мой первый ответ.

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

т.е. делать останов _не_ своей ветки = есть зло. Так понятней? Вы не можете гарантировать, не зная внутреннего устройства ветки, что она тормознётся _корректно_ !!! Т.е. если вы затачиваетесь на внутреннюю логику поведения библиотеки при том или ином Вашем внешнем воздействии - то это чревато в будущем(как минимум). Т.е. при незначительном изменении кода самой библиотеки, Вы рискуете опять начать всё сначала (разведку, перепрограммирования своего кода вызова-останова, тестирование).


если идёт речь о не понимании как это сделать _внутри_ библиотеки - то это попытка второго моего ответа. Т.е. внутри библиотеки, должно быть обеспечено на фазе старта:
1) вход
2) захват общих ресурсов, если есть. подготовка к старту нитки.
3) подъём нитки.
4) ожидание до окончания синхронной фазы подъёма (!!! эту фазу многие пропускают. чревато проблемами при ударных нагрузках на систему в целом).
5) обработка ошибок
6) выход.

При этом внутри подымаемой нитки код будет приблизительно следующий
1) вход
2) захват локальных (ведомых данной ниткой) ресурсов
3) обработка ошибок
4) сигнализация паренту о готовности к работе, либо ошибке.
5) уход на ожидание события либо саму работу.
---
6) бла-бла-бла (работа типа)
----
7) ожидание начала останова нитки из вне.
8) освобождение своих локально захваченных ресурсов.
9) обработка ошибок
10) сигнализация об успешном окончании нитки, либо ошибке
11) выход.

с 1 по 5 пункты зеркальны к пунктам с 7 по 11. Т.е. если Вы в нитке частично завхатили ресурсы, то и на выходе Вы должны освободить только захваченные ресурсы.

код останова будет выглядеть приблизительно следующим.
1) вход
2) выставили сигнальчик нитке об останове.
3) ожидание останова нитки.
4) освобождение общих ресурсов, если есть
5) обработка ошибок
6) выход


Для обеспечения постоянного мониторинга связи парент-чайлд применяют не блокирующие функции ввода-вывода. Обычно у чайлда всю работу делают квантованной и обрабатывают порциями. При этом обычно выделяется основной цикл, внутри которого обрабатывают в том числе и сигналы приходящие от парента.

Давайте я расскажу ход моих мыслей, когда я читал ваши ответы.



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


С этим я соглашусь. Эту мысль я отразил в своей фразе ...Вроде как напрашивается только одно решение

Затем.



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

Так же я писал.

Вот об этом и вопрос. О конктретной части правда, как в функции stop() реализовать корректый останов потока?

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

Тут либо я тугой, либо кто то другой. Если я, то признаю , если будут аргументы.

В дочернем потоке вызвать
pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
перед вызовом блокируемой функции.
Тогда дочерний поток может быть завершен с помощью pthread_cancel в любой момент, в т.ч. когда висит на вызове блокируемой функции.

а где освобождить ресуры?

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

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

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

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

моя фраза:

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

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

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

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

дальше...



простите но в

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

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

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

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

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

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

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