Здравствуйте. Создаю поток CreateThreed(...), как его убить. WaitForSingleObject не использую, просто создаю поток, он мне нужен для загрузки ресурсов. По идее он должен сам убится, когда функция возвращает 0, но у меня он и дальше висит:(

в Windows лучше использовать beginthreadex/endthreadex



совершенно напрасно батенька.  достаточно дельный и простой способ проконтролировать жизнедеятельность потока.

это вы как определили? Диспетчер потоков убъет его когда будет время....

HANDLE закрываешь?
Можно прям так:
CloseHandle(CreateThreed(...));

это только обнуляет описатель, после чего его нельзя использовать, однако это не значит, что сам поток уничтожен. 

По классике:

 Почему напрасно? в моем случае поток должен отработать и убится(я так думаю). Мне он нужен только один оаз.

mrbrooks, 
, тоесть return 0??

Это сообщение отредактировал(а) Graf_h - 4.6.2009, 11:21

контроль наше все   



  

mrbrooks,  спасибо

Прежде чем говорить такое и приводить цитаты про :


неплохо бы разобраться, что человеку нужно.
Во-первых раз тема в этом разделе, то ненадо давать советов, что лучше использовать beginthreadex вместо CreateThread, Windows тут ни при чём.
Во-втиорых каким образом в уничтожении потока нам поможет WaitForSingleObject совершенно не ясно, разве что хендл прикрыть по его завершении. Но если он не нужен, то лучше вызвать CloseHandle сразу после CreateThread.
В третьих, если поток создаётся с помощбю CreateThread, то почти никакой разницы между return ExitStatus и ExitThread(ExitStatus) нет. По крайней мере я не вижу никакой, кроме того, что при ExitThread(ExitStatus) можно стек вернуть на в том состоянии, в котором он был на входе в поток.


Graf_h, 
Чтобы потоки не висели закрывай хендл потока, как только он тебе больше не нужен(Не надо ждать завершения самого потока, ему всё равно, закроешь ты хендл или нет) т.е. слушай, что сказал  bugmenot. А чтобы знать когда применять CreateThread, а когда нет, прочитай Рихтера и думай мозгом

Это сообщение отредактировал(а) asd - 4.6.2009, 12:49

Тебя вот забыл спросить. Просто не дождался.


RTFM


Тебя не проведешь. Это ты у нас гений. 


Кого волнует что ты видишь?

mrbrooks
Однако, а хоть 1 аргумент? И по поводу чего мне идти доки читать?

вообще-то разница может быть довольно значительной:


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

мозгом тут нужно думать независимо от того, надо ли ждать завершения потока или нет

M GremlinProg

mrbrooks, asd, спокойствие, страшного пока ни чего не случилось

asd, дорогой друг.
1. Желательное использование beginthreadex/endthreadex в Windows при программировании на С++ не плод моей фантазии. Это совет г-на Рихтера. 
2. Цитата - взята у того же г-на Рихтера по средствам копирования/вставки через буфер обмена.
3. WaitForSingleObject позволяет узнать завершился ли поток или нет. Подробности тут. И опять таки - см. г-на Рихтера. 

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

Добавлено через 1 минуту и 18 секунд
GremlinProg, да все вроде ок   просто спорим.

Я не совсем понял эту разницу, но вот что я знаю наверняка:
При return-е, функция возвращается в kernel32.dll, а там сразу вызывается тот же ExitThread.


Не все люди пишут на С++, я например на С пишу.


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


Да, слушайте меня! 

Стоп. ExitThread, естественно, надо вызывать, когда ф-ия потока уже всё освободила и сделала всё что нужно. Фактически я говорю об идентичности 
return rv; 
и 
ExitThread(rv);
если этот поток был создан через CreateThread, ибо после return ExitStatus мы попадаем на



В вашем коде 
rv = MainRoutine(...);
это вызов
DWORD Routine(...) ?
если так, то ясно, что так вызывать ExitThread нельзя.


mrbrooks, 
Всё это конечно хорошо, если мы пишем на с++ с использованием rtl. Раз тема находится в этом разделе и человек вызывает CreateThread, то я думаю, что пишет он на винапи. А мешать Винапи и beginthreadex/endthreadex бессмысленно. Если вы почитаете Рихтера внимательнее, то увидите, что он рекомендует вызавать beginthreadex/endthreadex по причинам, которые никак с виндой не связанны.



что делает WaitForSingleObject мне известно. Только проблема состоит в том, что.

И вот вопрос, зачем вызывать WaitForSingleObject? И чем он нам может почочь?

Резонно   

Согласен. Только имхо ее как раз и есть смысл вызвать после WaitForSingleObject или есть другие идеи. 


Резонно.


Согласен. Разговор шел о С++. 


не понял - почему же? можно по подробнее?




Тем что функция возвращает. Я же не утверждаю что только так можно определить завершился ли поток (WAIT_OBJECT_0) или нет (WAIT_TIMEOUT) - но как вариант имхо вполне годится.

Добавлено через 2 минуты и 13 секунд
И соответственно принимаем решения в зависимости от результата.

да, передумал название, пока набирал )

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

Если мешать вызовы rtl и винапи, то рано или поздно произойдёт нечто подобное тому, что описывает Рихтер в разделе "Ой, вместо _beginthreadex я по ошибке вызвал CreateThread". И не факт, что это единственный такой пример.



Так вопрос состоит не в том, чтобы определить, завершился ли поток, а в том, _почему_ он висит после return 0;




Зачем вам 2 перехода в ядро вместо 1? Wait.. ф-ии стоит вызывать, если нам нужно именно _дождаться_ завершения потока(к примеру он готовит какие-то данные для нас)

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

Ну это уже мазахизм

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



Ок. А как было определено что поток повис именно после return 0?

Добавлено через 3 минуты и 36 секунд

сейчас пробежал глазами  - ничего ужасного супротив  _beginthreadex обнаружено не было.

Добавлено через 6 минут и 45 секунд

сейчас пробежал глазами  - ничего ужасного супротив  _beginthreadex обнаружено не было.

Это сказал топикстартер.


Да дело на в _beginthreadex. У рихтера описан вариант вызова библиотечной ф-ии в потоке созданном через CreateThread. И кто сказал что подобных вещей не может произойти, если мы начнём совмещать другие вызовы  trl с вызовами других АПИ

Точно. Вопрос переадресуем  ему.



Волков боятся - в лес не ходить.  
Хотя ситуацию надо обмозговать.