Здравствуйте, algol, Вы писали:

A>Здравствуйте, Dima2, Вы писали:

D>>да, кстати, ведь по умолчанию m_bAutoDelete==TRUE ?
D>>тогда если поток завершился, то объекта pThread у тебя уже нет, программа у тебя должна падать время от времени, или в релизе.

A>Нет, объект остается, а вот хендл потока уже недействителен. Так что ничего не падает.
т.е. у тебя m_bAutoDelete==FALSE?

Здравствуйте, algol, Вы писали:

A>Нет, объект остается
откуда такая уверенность ?

A>Так что ничего не падает.
упадет

Здравствуйте, IvEv, Вы писали:

IE>А запускать поток с CREATE_SUSPENDED тоже не подходит по этой же причине?
IE>Да и еще посмотри что Вшьф2 предлагал

Автор: Dima2
Дата: 26.03.03

.

CREATE_SUSPENDED наверное тоже не подойдет. Точно также процесс может завершиться сразу после ResumeThread(). Предложение Димы2 должно решить проблему, хотя и потребует лишних трех строчек кода.

Здравствуйте, algol, Вы писали:

A>Здравствуйте, Дмитрий Наумов, Вы писали:

ДН>>Так я не понял, тебе что мешает что у тебя поток все дела успел сделать, шустрость его мешает?

A>Меня смущает то, что WaitForSingleObject может быть вызвана с неверным хендлом. Или просто не обращать на это внимания?

Не обращать. У системы есть таблица валидных хэндлов — пусть за этим и следит, а такая ситуация (вызов с уже невалидным хэндлом) все равно может случится, как ты не старайся, поэтому имхо это не криминал. Другое дело был ли создан твой поток и отработал ли он полностью?

Здравствуйте, Дмитрий Наумов, Вы писали:

ДН>Не обращать. <...>

вот я бы тебя побил бы за такие слова, если бы мог

есть же исходный код заглядывайте иногда.
ничего не смущает ?
тут же дело не хэндлах никаких и не таблицах.

void CWinThread::Delete()
{
    // delete thread if it is auto-deleting
    if (m_bAutoDelete)
        delete this;
}


CWinThread::~CWinThread()
{
    // free thread object
    if (m_hThread != NULL)
        CloseHandle(m_hThread);

.....
}

Здравствуйте, IvEv, Вы писали:

IE>т.е. у тебя m_bAutoDelete==FALSE?

Нет, стоит по умолчанию. Но pThread имеет какое-то значение. Проверить трудно, поскольку под отладчиком все работает нормально.

Здравствуйте, algol, Вы писали:

A>Здравствуйте, IvEv, Вы писали:

IE>>т.е. у тебя m_bAutoDelete==FALSE?

A>Нет, стоит по умолчанию. Но pThread имеет какое-то значение.
pThread может иметь какое угодно значение — это ведь адрес, но по адресу может уже ничего не быть.
Посмотри в memory, что находится по адресу pThread.

A>Проверить трудно, поскольку под отладчиком все работает нормально.
надолго ли?

Здравствуйте, Dima2, Вы писали:

D>Здравствуйте, Дмитрий Наумов, Вы писали:

ДН>>Не обращать. <...>

D>вот я бы тебя побил бы за такие слова, если бы мог

Не понял за что?

D>есть же исходный код заглядывайте иногда.
D>ничего не смущает ?
D>тут же дело не хэндлах никаких и не таблицах.

Таблицы о которых я говорил к CWinThread никакого отношения не имеют.

D>
D>

D>void CWinThread::Delete()
D>{
D>    // delete thread if it is auto-deleting
D>    if (m_bAutoDelete)
D>        delete this;
D>}

D>
D>CWinThread::~CWinThread()
D>{
D>    // free thread object
D>    if (m_hThread != NULL)
D>        CloseHandle(m_hThread);

D>.....
D>}
D>

Ну и что? Если есть флаг автоделит то он сам себя удалит, если нет, то пользователь обязан. В чем я то не прав?

Здравствуйте, Дмитрий Наумов, Вы писали:

ДН>>>Не обращать. <...>

BoundsChecker информирует о вызове системных функций с неправильным handle'ом. Не эстетично, когда в программе warning'и.

А вообще, если создавать тред через ::CreateThread(), но handle, ей возвращаемый, действителен и после завершения TreadProc (например, можно запросить ::GetThreadTimes() с этим handle'ом после завершения), поэтому сдается мне, что тред либо просто не стартует, либо его handle еще не успел оказаться в m_hThread, либо CWinThread его закрывает (смотреть так ли это не хочу принципиально).

Здравствуйте, Дмитрий Наумов, Вы писали:

ДН>>>Не обращать. <...>
D>>вот я бы тебя побил бы за такие слова, если бы мог
ДН>Не понял за что?

Ну как же за что?
В чем причина, что хэндл оказался невалиден? Да вобщем это неважно, валиден он или нет.
Ужас состоит в обращении к pThread->m_hThread, а ты спокойно говориш человеку "да не обращай внимания".

Здравствуйте, Dima2, Вы писали:

D>Здравствуйте, Дмитрий Наумов, Вы писали:

ДН>>>>Не обращать. <...>
D>>>вот я бы тебя побил бы за такие слова, если бы мог
ДН>>Не понял за что?

D>Ну как же за что?
D>В чем причина, что хэндл оказался невалиден? Да вобщем это неважно, валиден он или нет.
D>Ужас состоит в обращении к pThread->m_hThread, а ты спокойно говориш человеку "да не обращай внимания".

Эээ батенька, вы перевираете

WaitForSingleObject может быть вызвана с неверным хендлом.

Вот что я сказал и все. К конструкции pThread->m_hThread и возможности ее использования при убитом объекте я никак не ссылаюсь

Здравствуйте, Frostbitten, Вы писали:

F>Здравствуйте, Дмитрий Наумов, Вы писали:

ДН>>>>Не обращать. <...>

F>BoundsChecker информирует о вызове системных функций с неправильным handle'ом. Не эстетично, когда в программе warning'и.

F>А вообще, если создавать тред через ::CreateThread(), но handle, ей возвращаемый, действителен и после завершения TreadProc (например, можно запросить ::GetThreadTimes() с этим handle'ом после завершения), поэтому сдается мне, что тред либо просто не стартует, либо его handle еще не успел оказаться в m_hThread, либо CWinThread его закрывает (смотреть так ли это не хочу принципиально).

Имхо, как я уже говорил, НОРМАЛЬНЫМ (без всяких извращений типа слипов вначале треда) этого не избежать. Например, есть поток, запускающий другие десять и потом ждущий их завершения, причем длительность работы каждого из этих десяти зависит от внешних факторов. Вероятность того что к тому времени как мы все 10 запустим и станем ждать их на WaitForMulti... какой нибудь из них завершится больше нуля. Так что ситуация может случится... Другое дело, что, КАК ВЫ ПРАВИЛЬНО заметили, не стоит использовать зазря, без особой надобности всякие AfxBeginThread

Здравствуйте, Дмитрий Наумов, Вы писали:

ДН>Эээ батенька, вы перевираете
да нет, это ты мастер вырывать фразы из контекста.

WaitForSingleObject может быть вызвана с неверным хендлом

безусловно.

смотри в чем был вопрос
A>Меня смущает то, что WaitForSingleObject может быть вызвана с неверным хендлом. Или просто не обращать на это внимания?

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

Здравствуйте, Dima2, Вы писали:

D>Ну он вызывал не просто с невалидным хэндлом, а он давал этот невалидный хэндл через указатель неизвестно на что, а ты говориш все нормально, не обращай внимания. Вот за это я собирался тебя побить , ну да ладно выкрутился.

Типа пакт о ненападении?

Предлагаю сделать вывод:
Использование AfxBeginThread с "оставлением" m_bAutoDelete == TRUE и затем ЛЮБЫМ образом pThread->... — заведомо опасная ситуация == misdemeanor

Здравствуйте, algol, Вы писали:

[]

A>Нет, объект остается, а вот хендл потока уже недействителен. Так что ничего не падает.

ЕжеОбъект удаляется. А то, что по етому адресу еще что-то езть, то ето чистая случайность.
Посмотри
_AfxThreadEntry
AfxEndThread
в thrdcore.cpp