Профессионалы ! Как грохнуть ПОТОК по его ID ?

← →
zhmax (2002-04-10 08:22) [0]

Как грохнуть поток по его ID ?
Есть функция TerminateThread, но ей в качестве аргумента необходимо передавать handle на поток. А где-ж его взять то ?
МайкроСофт пишет, что нет никаких путей для получения handle из
ID для потока, и что сделано это, так сказать, в целях безопасности.
Однако, мне кажется способ есть, и о нём как всегда МайкроСофт умалчивает. Помогите, если можете.

← →
Digitman (2002-04-10 08:43) [1]

А куда у тебя этот handle делся, когда ты поток создавал ?
Ведь CreateThread() как раз handle и возвращает при успешном запуске потока.

← →
zhmax (2002-04-10 09:02) [2]

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

← →
Виктор Щербаков (2002-04-10 09:07) [3]

> необходимо пообрубать лишние или зависшие потоки в любом
> процессе

Интересно, как ты узнаешь какие именно потоки лишние или зависшие?

← →
zhmax (2002-04-10 09:14) [4]

Можно используя WMI определить какие потоки жрут память, процессорное время, или находятся в состоянии ожидани. Короче определение потока для выруба - это не проблема. Вопрос в том, как вырубить ?

← →
zhmax (2002-04-10 09:28) [5]

Ну что, нкто не знает ?

← →
zhmax (2002-04-10 10:10) [6]

When a new thread is created by the CreateThread or CreateRemoteThread function, a handle of the thread is returned. By default, this handle has full access rights, and

← →
Алексей Петров (2002-04-10 10:11) [7]

OpenThread - но только для Win2K и выше и для Win ME и выше

← →
zhmax (2002-04-10 10:23) [8]

Какая Dll и параметры функции не подскажешь ?

← →
Алексей Петров (2002-04-10 10:25) [9]

Platform SDK: DLLs, Processes, and Threads
OpenThread
The OpenThread function opens an existing thread object.

HANDLE OpenThread(
DWORD dwDesiredAccess, // access right
BOOL bInheritHandle, // handle inheritance option
DWORD dwThreadId // thread identifier
);
Parameters
dwDesiredAccess
[in] Specifies the desired access to the thread object. For operating systems that support security checking, this access level is checked against any security descriptor for the target thread. This parameter can be STANDARD_RIGHTS_REQUIRED or any combination of the following values. Value Description
SYNCHRONIZE Enables the use of the thread handle in any of the wait functions.
THREAD_ALL_ACCESS Specifies all possible access flags for the thread object.
THREAD_GET_CONTEXT Enables the use of the thread handle in the GetThreadContext function.
THREAD_QUERY_INFORMATION Enables the use of the thread handle to read certain information from the thread object, such as the exit code (see GetExitCodeThread).
THREAD_SET_CONTEXT Enables the use of the thread handle in the SetThreadContext function.
THREAD_SET_INFORMATION Enables the use of the thread handle to set certain information for the thread object.
THREAD_SET_THREAD_TOKEN Enables the use of the thread handle in the SetTokenInformation function to set the thread token.
THREAD_SUSPEND_RESUME Enables the use of the thread handle in the SuspendThread or ResumeThread function to suspend and resume the thread.
THREAD_TERMINATE Enables the use of the thread handle in the TerminateThread function to terminate the thread.

bInheritHandle
[in] Indicates whether the returned handle is to be inherited by a new process created by the current process. If this parameter is TRUE, the new process will inherit the handle.
dwThreadId
[in] Specifies the identifier of the thread to open.
Return Values
If the function succeeds, the return value is an open handle to the specified process.

If the function fails, the return value is NULL. To get extended error information, call GetLastError.

Remarks
The handle returned by OpenThread can be used in any function that requires a handle to a thread, such as the wait functions, provided you requested the appropriate access rights. The handle is granted access to the thread object only to the extent it was specified in the dwDesiredAccess parameter.

When you are finished with the handle, be sure to close it by using the CloseHandle function.

Requirements
Windows NT/2000 or later: Requires Windows 2000 or later.
Windows 95/98/Me: Requires Windows Me.
Header: Declared in Winbase.h; include Windows.h.
Library: Use Kernel32.lib.

See Also
Processes and Threads Overview, Process and Thread Functions, CloseHandle, GetExitCodeThread, GetThreadContext, ResumeThread, SetThreadContext, SetTokenInformation, SuspendThread, TerminateThread

Platform SDK Release: February 2001 Contact Platform SDK Order a Platform SDK CD Online

Requirements
Windows NT/2000 or later: Requires Windows 2000 or later.
Windows 95/98/Me: Requires Windows Me.
Header: Declared in Winbase.h; include Windows.h.
Library: Use Kernel32.lib.
See Also
Processes and Threads Overview, Process and Thread Functions, CloseHandle, GetExitCodeThread, GetThreadContext, ResumeThread, SetThreadContext, SetTokenInformation, SuspendThread, TerminateThread

← →
SPeller (2002-04-10 10:44) [10]

А зачем обрубать потоки а не весь процесс ? Кажется мне, что программа после таких действий работать не будет (как надо по крайней мере). Создавая поток, она рассчитывает, что он работает, а на самом деле его нет !... И как ей быть кроме как выплюнуть ошибку и закрыться ?

← →
SPeller (2002-04-10 10:44) [11]

← →
Alx2 (2002-04-10 10:58) [12]

Может быть спасет Thread32First:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/perfmon/toolhelp_66gk.asp

← →
paul_shmakov (2002-04-10 12:21) [13]

2 zhmax:
комментарий о целесообразности:

"Можно используя WMI определить какие потоки жрут память, процессорное время, или находятся в состоянии ожидани. Короче определение потока для выруба - это не проблема."

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

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

← →
SPeller (2002-04-10 12:41) [14]

"Обрубать" потоки это всёравно что снять с вашей машины радиатор, чтобы не тратить воду и избавиться от лишнего веса. Можно снять покрышки, чтобы не тратить деньги на них. Можно убрать стёкла и оптику, подумаешь некрасиво, зато ездит и средства экономит!

← →
zhmax (2002-04-10 12:55) [15]

Спасибо всем за советы. Все реализовал, благо под руками был W2000. Обидно, что под NT такого нет и под W98.

Причина, по которой надо уничтожать поток, следующая :
Представьте, что есть мощная программа (С), к которой подключаются другие (К). Мощная программа (С) запускает новый поток, для работы с каждым из (К). Но возникает такая ситуация, что эти потоки - подвисают (по причине того, что (К) не дождавшись ответа от (С), закрылась), а как следствие - жрут память, время процессора и т.д.

← →
Digitman (2002-04-10 13:46) [16]

Причин, по которым "надо уничтожать поток" в идеале не должно быть. Если поток "завис", то это говорит только об одном - программер не предусмотрел некие нештатные ситуации, от которых зависит корректное выполнение и завершение потока.

Ситуация с (С) и (К) не является исключением. Грамотно реализованный алгоритм (К) должен при старте потока в (С) передать ему параметром хэндл некоего созданного им же объекта интерпроцессной синхронизации (мьютекса, семафора, атома - чего душа пожелает). Тогда работающий в (С) поток в любой момент может обратиться к переданному ему параметрически объекту синхронизации с целью определения условий для продолжения/завершения своей работы.

При таком подходе в приведенной тобой "нештатной" ситуации условия завершения потока в (с) просты до безобразия :

- если результатом обращения потока в (C) к объекту синхронизации (с помощью любой из удобных для тебя API-ф-ций проверки/ожидания, позволяющих это) будет WAIT_ABANDONED, это - прямой сигнал о том, что поток процесса (К) "покинул" созданный им объект синхронизации, не закрыв хэндл объекта штатно (принудительно снят с выполнения пользователем или ОС), либо поток процесса (К) закрыл хэндл объекта штатно, не дождавшись завершения потока процесса (С)

Это - лишь один из множества возможных вариантов решения явно "надуманной" тобой "проблемы".

Профессионалы ! Как грохнуть ПОТОК по его ID ? Найти похожие ветки