Здравствуйте.
Написал поточную функцию:

extern "C" __declspec(dllexport) DWORD WINAPI isThreadPing(LPVOID ispingparam)
 {    
............
     return 1;
 }

написал её вызов:

extern "C" __declspec(dllexport) DWORD isStartPing(char *isIPAddr, unsigned long istime, char* isfilename)
 {    
     HANDLE     ishandle;
     DWORD      isid;
     char *lparam = new char[255];
     struct  isPingParam *isthreadopt;                      // Укзатель на структуру параметров
     isthreadopt=(struct isPingParam*) lparam;
     isthreadopt->isIPAddr=isIPAddr;
     isthreadopt->is_time =istime;
     isthreadopt->isLogFile=NULL;
     ishandle=CreateThread(NULL, 0, &isThreadPing, isthreadopt, 0, &isid);
     if (ishandle == NULL ) return 0;
     return(isid);
 }

И вроде жизнь прекрасна, а по F11 студия упрямо не хочет заходить внутрь поточной функции, даже если внутри брейкпоинт поставить. И когда прохожу ее, то никакого нового потока в списке отладчика не обнаруживается, хотя хэндл был присвоен и id был присвоен, то есть функция создания потока отработала нормально. Вот я и сел в лужу... прошу о помощи. Буду благодарен за подробную информацию — потому как слаб пока, а сделать очень нужно.

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

A> Здравствуйте.
A>Написал поточную функцию:

A>а по F11 студия упрямо не хочет заходить внутрь поточной функции

И не должна.

A>, даже если внутри брейкпоинт поставить.

А вот здесь должна останавливаться если функция(и поток соотв.) не завершилась до того как.

Оберни свою isThreadPing в еще одну и поставь breakpoint на return из этой обертки.

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

A>>Написал поточную функцию:

A>>а по F11 студия упрямо не хочет заходить внутрь поточной функции

CS>И не должна.

Совершенно верно. Создается thread, который будет планироваться на выполнение, что бы выполнить Вашу ф-ию, а не вызывается ф-ия

A>>, даже если внутри брейкпоинт поставить.

CS>А вот здесь должна останавливаться если функция(и поток соотв.) не завершилась до того как.

CS>Оберни свою isThreadPing в еще одну и поставь breakpoint на return из этой обертки.

ну это лишнее. Достаточно поставить точку в начале ф-ии. Но все равно возможны варианты, например приложение завершилось (например из-за исключения) до получения управления этим потоком. Можно поставить WaitForSingleObject сразу после создания потока и проверки кода от CreateProcess

Здравствуйте, Сергей Мухин, Вы писали:
...
CS>>Оберни свою isThreadPing в еще одну и поставь breakpoint на return из этой обертки.
СМ>ну это лишнее. Достаточно поставить точку в начале ф-ии. Но все равно возможны варианты, например приложение завершилось (например из-за исключения) до получения управления этим потоком. Можно поставить WaitForSingleObject сразу после создания потока и проверки кода от CreateProcess

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

Поток живет, пока он не завершится сам, или его не убьют насильно.
Убить поток можешь, например, ты или OS, если завершает работу основной поток.
В любом случае любое убийство, даже потока — вещь плохая.
Если поток работает потенциально вечно, то его надо просить о том,
чтобы он завершил свою работу.
Как это сделать? Для этого у тебя целый арсенал разных средств.
В самом простейшем случае подойдет "зашаренная" между разными потоками общая переменная.

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

Здравствуйте, almer

какой ужасный код исключение в перемешку с кодами ошибок,
и плюс ресурсы за собой не подчищаешь.

A>Буду благодарен за подробную информацию — потому как слаб пока, а сделать очень нужно.

для начала вам несомненно стоит изучить инструмент,
например заштудировать Страуструпа.

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

S>Здравствуйте, almer

S>какой ужасный код исключение в перемешку с кодами ошибок,
S>и плюс ресурсы за собой не подчищаешь.

A>>Буду благодарен за подробную информацию — потому как слаб пока, а сделать очень нужно.

S>для начала вам несомненно стоит изучить инструмент,
S>например заштудировать Страуструпа.
по теме плз

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

А>Поток живет, пока он не завершится сам, или его не убьют насильно.
А>Убить поток можешь, например, ты или OS, если завершает работу основной поток.
А>В любом случае любое убийство, даже потока — вещь плохая.
А>Если поток работает потенциально вечно, то его надо просить о том,
А>чтобы он завершил свою работу.
А>Как это сделать? Для этого у тебя целый арсенал разных средств.
А>В самом простейшем случае подойдет "зашаренная" между разными потоками общая переменная.

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

информации 0. по теме есть?

Здравствуйте, Сергей Мухин, Вы писали:

СМ>информации 0. по теме есть?

Ну, если тебе не лень, то распиши ему все что к этому относится.
Я тоже почитаю

Здравствуйте, Сергей Мухин, Вы писали:

СМ> по теме плз

Да, да...
Пожалуйста по теме

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

A>Здравствуйте, Сергей Мухин, Вы писали:
A>...
CS>>>Оберни свою isThreadPing в еще одну и поставь breakpoint на return из этой обертки.
СМ>>ну это лишнее. Достаточно поставить точку в начале ф-ии. Но все равно возможны варианты, например приложение завершилось (например из-за исключения) до получения управления этим потоком. Можно поставить WaitForSingleObject сразу после создания потока и проверки кода от CreateProcess

A>Огромное спасибо — брейкпоинт + WaitSingleObject помогли, именно в WaitSingleObject вошел наконец в функцию и появился поток в окне отладчика. Да, наверное нужно было всего лишь дождаться начала его выполнения. Ну раз уж я тут, то хотелось бы узнать такой вариант: функция, создавшая поток завершилась, до окончания выполнения потока (притом что она библиотечная и её вызвали еще из экзэшника), поток или его данные умрут или мне все-таки повезет и он мирно будет пинговать компы и писать свой лог, пока не вызовут новую функцию — убить поток?

Ну я бы не стал писать программы (особенно многопоточные) не понимая сути. Поверь, многопоточные программы это очень сложно. или надо тупо локировать все и вся или стреляться. Перед написанием CreateThread надо понимать что такое: критические секции, потоки, мутексы, семафоры, евенты, а на самом деле еще больше

Удачи!

А>Убить поток можешь, например, ты или OS, если завершает работу основной поток.

Сорри что влезаю не по теме, но ос не убивает потоки по завершению "основного". Что легко проверить:
Потоки завершает вызов ExitProcess, прямой или стандартным рантаймом после выхода из main.
А вот так процесс будет жить минуту-

void __cdecl trd(void *)
{
::Sleep(60000);
}
void main()
{
__beginthread(trd, 0, 0);
::EndThread(0);
}

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

А>>Убить поток можешь, например, ты или OS, если завершает работу основной поток.

А>Сорри что влезаю не по теме, но ос не убивает потоки по завершению "основного". Что легко проверить:
А>Потоки завершает вызов ExitProcess, прямой или стандартным рантаймом после выхода из main.
А>А вот так процесс будет жить минуту-
А>

А>void __cdecl trd(void *)
А>{
А>::Sleep(60000);
А>}
А>void main()
А>{
А>__beginthread(trd, 0, 0);
А>::EndThread(0);
А>}
А>

совершенно верно, просто когда говорят об завершении гл thread обычно имеют ввиду выход из main со всеми вытекающими. Но так, конечно, точнее.

ps
только ExitThread (или _endthread) наверно