Как правильно "убить" зависший Thread

← →
Alex_C (2015-07-29 08:36) [0]

Столкнулся с такой проблемой: есть тред, получающий эпизодически достаточно большую порцию данных из инета, обрабатывающий ее и выводящий в окно основной программы. Если у пользователя стоит использование спящего режима, когда комп переходит в спящий режим тред зависает при получении данных (я так понимаю, что это происходит если комп перешел в спящий момент когда как раз велся прием данных).
При попытке выхода из программы пытаюсь завершить тред:
Terminate;
WaitFor - тут просто программа виснет, ожидая окончания работы треда.
Вопрос: как правильно сделать WaitFor но с указанием, сколько времени ждать окончания завершения заботы программы, а уж потом ее
TerminateThread(MyThread.Handle);?

← →
кгшзх © (2015-07-29 13:06) [1]

Вопрос: как правильно сделать WaitFor

Встречный вопрос: зачем тебе вторичный поток, если ты собрался делать ему WaitFor?
это все равно что весь код вторичного потока выполнить в главном.

← →
кгшзх © (2015-07-29 13:09) [2]

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

не пробовал ресьюмить его?

← →
Юрий Зотов © (2015-07-29 14:22) [3]

> Alex_C (29.07.15 08:36)

Terminate не завершает поток, а только выставляет его свойство Terminated. Чтобы поток завершился, в его методе Execute надо проверять это свойство и если оно true, то выходить из Execute. Если этого не делать, то Execute не завершается, поток тоже - и WaitFor будет ждать бесконечно.

← →
DVM © (2015-07-29 14:30) [4]

> кгшзх © (29.07.15 13:06) [1]

> Встречный вопрос: зачем тебе вторичный поток, если ты собрался
> делать ему WaitFor?

Как ты предлагаешь завершать вторичные потоки при завершении приложения?

← →
кгшзх © (2015-07-29 15:00) [5]

Как ты предлагаешь завершать вторичные потоки при завершении приложения?

Повторяю по слогам:
Зачем создавать вторичный, если из главного ему собираются делать WaitFor?

Про зависание/отвисание/терминэйт вообще пока речи не идет.
Речь про любой вторичный поток

Как ты предлагаешь завершать вторичные потоки при завершении приложения?

Они тупо должны ловить окончание процесса, завершение винды, етц.
Как это делает главный поток.
Ну и естественно вторичный надо оповещать о них самому.

← →
кгшзх © (2015-07-29 15:17) [6]

Terminate не завершает поток,

Так он не Terminate и вызывает

TerminateThread is used to cause a thread to exit.
When this occurs, the target thread has no chance to execute any user-mode code.

← →
Игорь Шевченко © (2015-07-29 15:36) [7]

> как правильно сделать WaitFor но с указанием, сколько времени
> ждать окончания завершения заботы программы, а уж потом
> ее
> TerminateThread(MyThread.Handle);?

А зачем ждать, если можно сразу убить ?

← →
Юрий Зотов © (2015-07-29 17:39) [8]

> кгшзх © (29.07.15 15:17) [6]

> Так он не Terminate и вызывает

Хм... а мне казалось, что он все же вызывает именно Terminate. А уж потом WaitFor.

Мне пора сменить очки?

← →
DVM © (2015-07-29 17:52) [9]

> кгшзх © (29.07.15 15:00) [5]

> Повторяю по слогам:
> Зачем создавать вторичный, если из главного ему собираются
> делать WaitFor?

В огороде бузина, в Киеве дядька. Как связаны две части твоего высказывания между собой?

Вторичный поток (если FreeOnTerminate = false) как раз правильно завершать именно с использованием WaitFor:

MyThread.Terminate;
MyThread.WaitFor;
MyThread.Free;

Что тебя смущает то?

← →
DVM © (2015-07-29 17:57) [10]

> кгшзх © (29.07.15 15:00) [5]

> Про зависание/отвисание/терминэйт вообще пока речи не идет.
>
> Речь про любой вторичный поток

А по моему речь как раз и идет про завершение потока при завершении приложения? нет?

> При попытке выхода из программы пытаюсь завершить тред:
> Terminate;
> WaitFor - тут просто программа виснет, ожидая окончания
> работы треда.

← →
кгшзх © (2015-07-29 18:00) [11]

а уж потом ее
TerminateThread(MyThread.Handle);?

В огороде бузина, в Киеве дядька. Как связаны две части твоего высказывания между собой?

Ты тупой штоле?

Реализуем длинный алгоритм.
Пхаем его во вторичный поток.
Запускаем.
Делаем WaitFor.
Смотрим что произошло.

Переносим свой длинный алгоритм в баттон1.клик
Запускаем.
Смотрим что произошло.

Ищем хоть одно отличие.
С точки зрения что нам дал вторичный поток в первом, и что не дал первичный во втором.

← →
DVM © (2015-07-29 18:03) [12]

> кгшзх © (29.07.15 15:00) [5]

> Они тупо должны ловить окончание процесса, завершение винды,
> етц.
> Как это делает главный поток.
> Ну и естественно вторичный надо оповещать о них самому.

Тут понимаешь ли есть нюансы. Очень часто при закрытии приложения требуется точно знать, что все вторичные потоки завершили свою работу, например, если эти потоки работали с каким-либо разделяемым между ними объектом, который тоже надо уничтожить при завершении. Но это мы можем сделать только после завершения работы потоков. Поэтому есть два варианта, либо получать от потоков какие то события о том, что они отработали, либо ждать их завершения по WaitFor.

← →
кгшзх © (2015-07-29 18:03) [13]

После этого снова пробуем ответить себе на кой хрен нам вторичный поток если мы ему собрались делать WaitFor

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

← →
DVM © (2015-07-29 18:05) [14]

> кгшзх © (29.07.15 18:00) [11]

>
> Ты тупой штоле?
>
> Реализуем длинный алгоритм.
> Пхаем его во вторичный поток.
> Запускаем.
> Делаем WaitFor.
> Смотрим что произошло.

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

← →
кгшзх © (2015-07-29 18:06) [15]

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

пространственно-временной континуум не сломается, если у тебя в процессе утекла пара десятков мегабайт памяти.

Таки снова вопрос: ну и нафига еще раз вторичный поток, если главный умирая освободит свои ресурсы сам, а вторичный сам по себе - фик.

← →
DVM © (2015-07-29 18:07) [16]

> кгшзх © (29.07.15 18:03) [13]
> После этого снова пробуем ответить себе на кой хрен нам
> вторичный поток если мы ему собрались делать WaitFor

Ты тупой что-ли? Чтобы он в фоне работал. Никто его не ждет сразу после запуска.

← →
DVM © (2015-07-29 18:10) [17]

> кгшзх © (29.07.15 18:06) [15]

> Таки снова вопрос: ну и нафига еще раз вторичный поток,
> если главный умирая освободит свои ресурсы сам, а вторичный
> сам по себе - фик.

Про огород бузину и дядьку перечитай. И не уклоняйся от первоначальной темы.

← →
кгшзх © (2015-07-29 18:14) [18]

Читаем сверху:

чувак создал нитку.
комп уснул.
нитка в суспенде.
он подходит и будит комп.
нитка в суспенде.

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

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

← →
DVM © (2015-07-29 18:23) [19]

> кгшзх © (29.07.15 18:14) [18]

> а нахрена мне здесь вторичный поток, если я уже прочитал
> что потоки это круто, не еще знаю что такое ресьюм

Resume вообще deprecated уже давно. Но не в этом дело.
Ты уж реши проблема в знаниях автора вопроса или в том, что ты не понял где и как именно автор использовал WaitFor, иначе как объяснить:

> Реализуем длинный алгоритм.
> Пхаем его во вторичный поток.
> Запускаем.
> Делаем WaitFor.
> Смотрим что произошло.

Ну не так у автора вопроса же.

Ну не так у автора вопроса же.

Что значит не так?

Каждый раз когда комп усыпает, усыпает его нитка.
И он кажный раз при просыпании собирается делать вэйтфор.
А так как компы усыпают не тогда, когда твоя нитка все сделала и ее можно убить, а в любое произвольное время, в том числе если я отошел покурить и на клаве нажал "сон"

то получается:
у автора нитка, в N строк кода и на каждой (каждой! етиамать) строчке ее поджидает вызов WaitFor.

ага. на каждой.
а она спит в это время.

есть тред, получающий эпизодически достаточно большую порцию данных из инета

"большую порцию данных из инета" в фоне можно вынуть в основном потоке, используя асинхронный xmlhttprequest

А где у автора написано, что он собирается вызывать Waitfor после каждого пробуждения компьютера. По-моему, у него Waitfor только при завершении программы вызывается.

А где у автора написано, что он собирается вызывать Waitfor после каждого пробуждения компьютера.

емае ты логичен как аристотель.
комп уснул, потом проснулся, сразу после просыпания он гасит программу.

вместо того чтобы продолжить работу. компы же пробуждают в основном чтобы не работать дальше.

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

вот там-то у него и написано (между строк)

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

да ладно

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

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

Спящие так спящими и останутся, активные на момент ухода в спячку из неё тоже вернутся активными.

" Как правильно "убить" зависший Thread "

Правильно - найти почему он типа "зависший" (спящий режим это катализатор, а не причина ошибки)

ЗЫ.
кгшзх, шо, потоки!? - да Вы просто не умеете их готовить! ))

Как правильно "убить" зависший Thread Найти похожие ветки