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

AA>Пол-кода переписывать чтобы всунуть WaitForSingleObject и заменить SuspendThread на ResetEvent? Какой то у вас код неправильный
Не пол-кода, а "всего" полмегабайта — сущий пустяк для атомной энергетики Впрочем, это тема для отдельного вопроса — люди, где мне взять прямые руки?

Вы хотели юзать SuspendThread в проге управляющей атомным реактором?
ггг.. /me спас мир

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

AA>Вы хотели юзать SuspendThread в проге управляющей атомным реактором?
AA>ггг.. /me спас мир
шутка. шутка это была.

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

AA>SuspendThread _ВСЕГДА_ зло и кака. И это не голословное утверждения из разряда "goto — зло", а реально не раз потвержденный на практике факт. На момент вызова SuspendThread поток может исполнять глобально синхронизированный код в каком нить memory manager'е или просто в системых библиотеках.

Перефразируя Будду, корень зла — это не SuspendThread, а незнание истины.

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


Если проблемы вызваны непродуманным кодом

Автор: apple-antonovka
Дата: 08.09.06

— это проблема кода, а не SuspendThread. (кто мешает использовать отдельный хип для усыпляемого треда?)

GN>Если проблемы вызваны непродуманным кодом

Автор: apple-antonovka
Дата: 08.09.06

— это проблема кода, а не SuspendThread. (кто мешает использовать отдельный хип для усыпляемого треда?)

Проблемы SuspendThread в том что исполняющий код в принципе не может точно быть уверенным в том что тот кого он успыляет находится в безопасном месте. Если вы думаете что вы уверены — вы ошибаетесь. Ядро может использовать userspace потоки для исполнения своих APC, без их ведома. Кроме того многие АПИ функции документированно расширябельны — хуки, LSP, и конкретная их имплементация их никак не гарантируется. Пример с планировщиком ядра неудачен тк код планировщика работает на высоком IRQL и управляет потоками работающими на низких. В userspace такого механизма не предусмотрено, потому единственно безопасный вызов SuspendThread() — SuspendThread(GetCurrentThread()).

apple-antonovka wrote:
> Проблемы SuspendThread в том что исполняющий код в принципе не может
> точно быть уверенным в том что тот кого он успыляет находится в
> безопасном месте. Если вы думаете что вы уверены — вы ошибаетесь.
> Ядро может использовать userspace потоки для исполнения своих APC, без их
> ведома.
Тут подробнее. Для каких целей? И чем тут помешает SuspendThread?

> Кроме того многие АПИ функции документированно расширябельны —
> хуки, LSP, и конкретная их имплементация их никак не гарантируется.
И что? Чем это отличается от вытеснения потока с хуком другим потоком?

> Пример с планировщиком ядра неудачен тк код планировщика работает на
> высоком IRQL и управляет потоками работающими на низких.
Мимо. Поток при обработке хука или работы в крит. секции может быть
запросто вытеснен на неопределенное время другим потоком (например, если
кто-то решил себе поставить realtime-приоритет) так как ядру это
абсолютно фиолетово.

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

C>apple-antonovka wrote:
>> Проблемы SuspendThread в том что исполняющий код в принципе не может
>> точно быть уверенным в том что тот кого он успыляет находится в
>> безопасном месте. Если вы думаете что вы уверены — вы ошибаетесь.
>> Ядро может использовать userspace потоки для исполнения своих APC, без их
>> ведома.
C>Тут подробнее. Для каких целей? И чем тут помешает SuspendThread?
для исполнения completeion routine асинхронных операций ввода-вывода например. Чем чревато — читайте мыше.

>> Кроме того многие АПИ функции документированно расширябельны —
>> хуки, LSP, и конкретная их имплементация их никак не гарантируется.
C>И что? Чем это отличается от вытеснения потока с хуком другим потоком?
Не понимаю, причем тут вытеснение потоков.


>> Пример с планировщиком ядра неудачен тк код планировщика работает на
>> высоком IRQL и управляет потоками работающими на низких.
C>Мимо. Поток при обработке хука или работы в крит. секции может быть
C>запросто вытеснен на неопределенное время другим потоком (например, если
C>кто-то решил себе поставить realtime-приоритет) так как ядру это
C>абсолютно фиолетово.
Извините, но IRQL и приоритет потока вещи несколько разного гхм.. плана. Весь userspace код исполняется га IRQL=PASSIVE_LEVEL независимо от того приоритета потока, о котором вы пишете. Это раз.
Два — то что поток может быть вытеснен никто не спорит, он и будет вытестен если найдутся кандидаты. Речь о том что остановка потока в то время когда он исполняет некий вызов (системы, third-party library etc) чревата тем что пока замороженный поток будет находится внутри критической секции (о который вы не знаете, для вас это просто вызов функции) и не позволит никакому другому потоку вашего процесса туда залезть (читайте, вызов любой функции той библиотеки другим потоком вашего процесса приведет к зависанию другого потока).

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

AA>SuspendThread отличается от TerminateThread только тем что не приводит к утечке ресурсов,

TerminateThread так же приводит к утечке ресурсов. Освобождение стека потока.

Автор:
Дата: 25.08.06

AA>а в тех ситуациях когда TerminateThread убивает апликуху SuspendThread ее обычно просто завешивает

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

AA>Проблемы SuspendThread в том что исполняющий код в принципе не может точно быть уверенным в том что тот кого он успыляет находится в безопасном месте.

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

AA>Если вы думаете что вы уверены — вы ошибаетесь. Ядро может использовать userspace потоки для исполнения своих APC, без их ведома.

Добавлю, что ISR так же могут выполняться в контексте любого треда, но по их завершению контекст восстанавливается. А какие от этого могут быть проблемы?

AA>Кроме того многие АПИ функции документированно расширябельны — хуки, LSP, и конкретная их имплементация их никак не гарантируется.

Думаю, никто не будет вызывать SuspendThread так же и для тредов читающих большой файл (по сети).

AA>Пример с планировщиком ядра неудачен тк код планировщика работает на высоком IRQL и управляет потоками работающими на низких.

Действительно, планировщик работает на IRQL DPC_LEVEL, а треды прерываются аж на CLOCK2_LEVEL. Причем, это происходит асинхронно (в отличие от синхронного SuspendThread). Это работает не только для юзерлендных тредов (PASSIVE_LEVEL), но и почти для всех возможных вообще. И ядро NT работает так уже много лет.

Говоря о неудачности моего примера, я бы сказал, что SuspendThread (в отличие от прерываний планировщиком) исключает тред из списка готовых к исполнению. Так что нужно предусмотреть гарантированную возможность повторного включения — но это в наших руках.

Возьмём тот же пример с хипом.
Стандарт языка С ничего не знает о тредах. Поэтому при раелизации стандартной библиотеки разработчик волен имплементировать malloc как ему захочется, и выделять из общего для всех тредов пула (нужна синхронизация) — это лишь одно из решений.
У разработчика конкретной библиотеки было 2 пути: учесть возможные проблемы, и тогда SuspendThread будет работать, или ничего не далать и объвить его "неправильным". Они пошли по простому пути.

AA>В userspace такого механизма не предусмотрено, потому единственно безопасный вызов SuspendThread() — SuspendThread(GetCurrentThread()).

Пример с расчетами полетов на Марс

Автор:
Дата: 08.09.06

(при правильном дизайне) вполне позволяет безопасно использовать SuspendThread. Установка низкого приоритета

Автор: apple-antonovka
Дата: 08.09.06

— тоже хорошее решение, но что, если юзер хочет кнопочку "pause"? Опрашивать переменную в цикле... это путь к 100% загрузки CPU и куча copy-paste WaitForSingleObject — вызов ядра (непосредственно планировщика — по сути, закат Солнца вручную).

Без SuspendThread некоторые вещи не возможны в принципе (например — вменяемый отладчик), некторые решаются заметно сложнее, и называть её "чистое зло и ошибка эволюции" — ИМХО похоже на теорию, потверждаемую ошибочной практикой. Я бы сказал, что бездумное применение этой функции может породить проблемы... но так можно о многом сказать

PS: Кстати, "вред" от усыпления тредов можно понаблюдать используя Process Explorer.

GN>Возьмём тот же пример с хипом.
GN>Стандарт языка С ничего не знает о тредах. Поэтому при раелизации стандартной библиотеки разработчик волен имплементировать malloc как ему захочется, и выделять из общего для всех тредов пула (нужна синхронизация) — это лишь одно из решений.
GN>У разработчика конкретной библиотеки было 2 пути: учесть возможные проблемы, и тогда SuspendThread будет работать, или ничего не далать и объвить его "неправильным". Они пошли по простому пути.
Он неправильный Дело не в объявлении. Просто эта функция предоставляет низкоуровневое управление над объектом, который вы не полностью контролируете на том уровне на котором пытаетесь управлять.
Вот вы опять начинаете доказывать абстракцию на детяльных примерах, и опять неудачно
1) Память выделенная потоко-независимым хипом сама по себе потоко-зависимая. Те выделив память в отдном потоке освободить в другом не выйдет. Это уже не malloc
2) Память для этого придется выделять из общего хранилища процесса. Обращения к которому будут синхронизированы.
ХОТЯ. Вообще говоря raw VirtualAlloc/Free можно использовать на чистой системе с SuspendThread т.к. SuspendThread останавливает юзерский код, если поток исполняется в кернеле — он доделывает то что начал (по кр мере я так думаю), (вот это и назыается — управление над полностью контролируемым объектом — для ядра SuspendThread безопасен). Но пример с менежером памяти — это одна из множества потенциальных проблем. И даже использование безопасности VirtualAlloc/Free по отношению к SuspendThread — это уже опора на implementation details конретной функции под конкретной версией конкретной чистой ос. В другой системе, даже с такой же ОС, эту функцию может похукать мега-твикер-оптимизатор, а шишки покатяться на вас .


AA>>В userspace такого механизма не предусмотрено, потому единственно безопасный вызов SuspendThread() — SuspendThread
GN>Без SuspendThread некоторые вещи не возможны в принципе (например — вменяемый отладчик), некторые решаются заметно сложнее, и называть её "чистое зло и ошибка эволюции" — ИМХО похоже на теорию, потверждаемую ошибочной практикой. Я бы сказал, что бездумное применение этой функции может породить проблемы... но так можно о многом сказать
Вот не надо, отладчик — это отдельный процесс , и то он не юзает SuspendThread, а юзает генерацию исключения (банальный int 3) в потоке созданном через CreateRemoteThread в удаленном процессе и далее — WaitForDebugEvent. Про то как конкретно эти функции реаилизованы — плз не рассказывать. Абстрагируйте все внешние вызовы как черный ящик

GN>PS: Кстати, "вред" от усыпления тредов можно понаблюдать используя Process Explorer.
WaitForSingleObject можно делать после проверки булевской переменной и не часто (я сам физик по образованию и потому прекрасно представляю себе что есть расчет траектории полета на марс , там будет куча редкоисполняемых мест куда мона всунуть этот вэйт, как и в любом другом алгоритме.

Нет ну да вообще говоря поток выполняющий код типа for(;); мона относительно безопасно суспендить, но даже этого я бы не стал делать, мало ли что там компилер напихает , стандарт нигде не описыват что конкретно написанный код на С++ не вызовет какие нить функции синхронизации.

Вообще просто функция SuspendThread — одна из тех функций которые действительно не стоило делать в win32 api, думаю микрософтовские программеры это уже 100 раз поняли, но никуда не деться — обратную совместимость надо соблюдать.

Здравствуйте, apple-antonovka,

AA>Дело не в объявлении. Просто эта функция предоставляет низкоуровневое управление над объектом, который вы не полностью контролируете на том уровне на котором пытаетесь управлять.
AA>Вот вы опять начинаете доказывать абстракцию на детяльных примерах, и опять неудачно
AA>1) Память выделенная потоко-независимым хипом сама по себе потоко-зависимая. Те выделив память в отдном потоке освободить в другом не выйдет. Это уже не malloc

Память можно освободить даже в адресном пространстве чужого процесса, что же говорить о своём Откуда там потокозависимость возьмётся? У каждого хипа свой хендл? Ну дык передавать их между тредами можно, хотя при нормальном дизайне не знаю, зачем

AA>2) Память для этого придется выделять из общего хранилища процесса. Обращения к которому будут синхронизированы.

1) Каждый тред может использовать отдельный хип.
2) Память для рабочего треда может выделять другой тред.

AA>ХОТЯ. Вообще говоря raw VirtualAlloc/Free можно использовать на чистой системе с SuspendThread т.к. SuspendThread останавливает юзерский код, если поток исполняется в кернеле — он доделывает то что начал (по кр мере я так думаю)

Не факт ведь, что правильно думаете. И на этом строите какие-то проблемы с SuspendThread. Эта функция (точнее, KeSuspendThread) поднимает IRQL до DISPATCH_LEVEL, лочит базу данных планировщика и ставит пустую APC усыпляемому треду. Так что тред запросто может быть усыплен и в ядре.

AA> (вот это и назыается — управление над полностью контролируемым объектом — для ядра SuspendThread безопасен). Но пример с менежером памяти — это одна из множества потенциальных проблем.

Ага, вот еще: 2 треда вызывают SuspendThread друг для друга Но ничего страшного из этого не выйдет, см. выше.

Все возможные проблемы SuspendThread документиррованы в MSDN:

Calling SuspendThread on a thread that owns a synchronization object, such as a mutex or critical section, can lead to a deadlock if the calling thread tries to obtain a synchronization object owned by a suspended thread

Всё. Если обеспечить невозможность этого — можно использовать.

AA>И даже использование безопасности VirtualAlloc/Free по отношению к SuspendThread — это уже опора на implementation details конретной функции под конкретной версией конкретной чистой ос. В другой системе, даже с такой же ОС, эту функцию может похукать мега-твикер-оптимизатор, а шишки покатяться на вас .

Подозреваю, что демагогия Кто угодно может криво похукать что угодно, и ОС упадёт в BSOD.

GN>>Без SuspendThread некоторые вещи не возможны в принципе (например — вменяемый отладчик)
AA>Вот не надо, отладчик — это отдельный процесс

Прям таки обязательно — процесс? Вот цитата из MSDN о SuspendThread:

To avoid this situation, a thread within an application that is not a debugger should signal the other thread to suspend itself.

AA> и то он не юзает SuspendThread, а юзает генерацию исключения (банальный int 3)

Остановился один из тредов на дебажном событии, что с остальными делать?

AA> в потоке созданном через CreateRemoteThread в удаленном процессе и далее — WaitForDebugEvent.

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

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

Марс и циклы — это частный случай. Даже с циклами, наверное, будет разница — 20 дней или 22 считать из-за постоянных WaitForSingleObject.

AA>Нет ну да вообще говоря поток выполняющий код типа for(;); мона относительно безопасно суспендить, но даже этого я бы не стал делать, мало ли что там компилер напихает , стандарт нигде не описыват что конкретно написанный код на С++ не вызовет какие нить функции синхронизации.

Откуда в C++ функции синхронизации взялись? Пока еще не вступил в силу C++09. Так что "какие нить функции" — целиком на совести разработчиков библиотеки. Подчеркну, что возможно реализовать эту библиотеку с поддержкой безопасного усыпления тредов. Точнее, когда сама библиотека не сможет оказаться источником проблем. А в своём коде пользователь и без тредов может такой каши наварить... это да.

AA>Вообще просто функция SuspendThread — одна из тех функций которые действительно не стоило делать в win32 api, думаю микрософтовские программеры это уже 100 раз поняли, но никуда не деться — обратную совместимость надо соблюдать.

ИМХО они думают: "It's not a bug, it's a feature" Даже привели в документации универсальный способ безпроблемного использования. Он потому такой и "через **", что универсальный

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

AA>Вообще просто функция SuspendThread — одна из тех функций которые действительно не стоило делать в win32 api, думаю микрософтовские программеры это уже 100 раз поняли, но никуда не деться — обратную совместимость надо соблюдать.

Проверил. Поставил на неё breakpoint. Explorer её вызывает и редактор от студии 2005 (экспресс) а так же Janus, судя по всему из .NET FrameWork

apple-antonovka wrote:
> C>Тут подробнее. Для каких целей? И чем тут помешает SuspendThread?
> для исполнения completeion routine асинхронных операций ввода-вывода
> например. Чем чревато — читайте мыше.
Вроде бы ничем не чревато. Ну не дойдут данные, и что?

>> > Кроме того многие АПИ функции документированно расширябельны —
>> > хуки, LSP, и конкретная их имплементация их никак не гарантируется.
> C>И что? Чем это отличается от вытеснения потока с хуком другим потоком?
> Не понимаю, причем тут вытеснение потоков.
В чем может быть проблема с хукнутым API и SuspendThread, которая не
проявится на установке приоритета idle и другом realtime-потоке?

> C>Мимо. Поток при обработке хука или работы в крит. секции может быть
> C>запросто вытеснен на неопределенное время другим потоком (например, если
> C>кто-то решил себе поставить realtime-приоритет) так как ядру это
> C>абсолютно фиолетово.
> Извините, но IRQL и приоритет потока вещи несколько разного гхм.. плана.
Причем здесь IRQL?

> Два — то что поток может быть вытеснен никто не спорит, он и будет
> вытестен если найдутся кандидаты. Речь о том что остановка потока в то
> время когда он исполняет некий вызов (системы, third-party library etc)
> чревата тем что пока замороженный поток будет находится внутри
> критической секции
Да. Но точно такая же ситуация возникнет, если я закручу
приоритет у другого процесса.

> (о который вы не знаете, для вас это просто вызов
> функции) и не позволит никакому другому потоку вашего процесса туда
> залезть (читайте, вызов любой функции той библиотеки другим потоком
> вашего процесса приведет к зависанию другого потока).
Это все решается контролем за тем, что используется потоком. Лично делал
систему на fibers+threads, в которой организовывался самодельный
scheduler. Никаких проблем не было.

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

AA>SuspendThread, ResumeThread, TerminateThread и отчасти ExitThread/_exitthread — чистое зло и ошибка эволюции. Поток должен усыплятся когда он сам этого ждет. Каким нить мутексовым/семафоровым локом.

В общем-то да, только как ты вытесняющую многозадачность без этой ошибки эволюции сделаешь

Дебаггер отдельные процесс, не имеющий в юзерспейсе никаких синхронизированных объектов с тем кого он дебагит. Поток в удаленном процессе создает windbg.

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

#include <stdlib.h>
#include <process.h>
#include <windows.h>

void __cdecl thread(void *p)
{
for(;)
{
void *p=malloc(0x100000);
Sleep(1);
free(p);
}
}

int main(int argc, char* argv[])
{
HANDLE h = (HANDLE)_beginthread(thread,0,NULL);

for(;;)
{
printf("[%08x] I'm still alive!\n",::GetTickCount());
SuspendThread(h);
void *p=malloc(0x100000);
free(p);
ResumeThread(h);
Sleep(1);
}

return 0;
}

Следующий пример отлично иллюстрирует дедлок в системной функции, по кр мере на моей системе (ХР/СП2). Зависшую консольную апликуху даже Ctrl+C не берет

#include <stdlib.h>
#include <process.h>
#include <windows.h>

void __cdecl thread(void *p)
{
    for(;;)
    {
        ::DeleteFile("foooooooooooooooooooooooooooooooooooooooooooooooooooooooooo1");
    }
}

int main(int argc, char* argv[])
{
    HANDLE h = (HANDLE)_beginthread(thread,0,NULL);
    
    for(;;)
    {
        printf("[%08x] I'm still alive!\n", ::GetTickCount());
        ::SuspendThread(h);
        ::DeleteFile("foooooooooooooooooooooooooooooooooooooooooooooooooooooooooo2");
        ::ResumeThread(h);
        ::Sleep(0);
    }
    
    return 0;
}

И даже так (дедлок в CRT):

#include <stdlib.h>
#include <process.h>
#include <windows.h>

void __cdecl thread(void *p)
{
    for(;;)
    {
        printf("[%08x] I'm still alive too!\n",
            ::GetTickCount());
    }
}

int main(int argc, char* argv[])
{
    HANDLE h = (HANDLE)_beginthread(thread,0,NULL);
    
    for(;;)
    {
        SuspendThread(h);
        printf("[%08x] I'm still alive!\n",
            ::GetTickCount());
        ResumeThread(h);
        Sleep(0);
    }
    
    return 0;
}

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

AA>Дебаггер отдельные процесс, не имеющий в юзерспейсе никаких синхронизированных объектов с тем кого он дебагит.

Давайте не будем обобщать. Во-первых, процесс в виндовсе не является исполняемой сущностью, а во-вторых никто не запрещает сделать поток-debigger в адресном пространстве отлаживаемого процесса. В MSDN про это прямо написано.

AA>Поток в удаленном процессе создает windbg.

Можно указать этот дополнительный тред на картинке:

?

AA>Спор перетекает в бесполезный флейм.

Ну да, это как "goto — вселенское зло".

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

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

Автор: gear nuke
Дата: 11.09.06

другой компании [размеры шварца поскипаны].

AA>Скомпилируйте пример ниже чтоб все что я писал выше не было голословным.

[]

Извините, не вижу смысла компилировать код с (намеренными?) ошибками (про которые написано в MSDN). Может быть следует убрать в треде printf() ?

GN>Давайте не будем обобщать. Во-первых, процесс в виндовсе не является исполняемой сущностью, а во-вторых никто не запрещает сделать поток-debigger в адресном пространстве отлаживаемого процесса. В MSDN про это прямо написано.
Причем тут это? (Признак флеймера — использование общеизвестных истин в качестве "доказательств", тогда как они никакой логической связи к этому не имеют)

AA>>Поток в удаленном процессе создает windbg.

GN>Можно указать этот дополнительный тред на картинке:
GN>
GN>?
use Attach to active process плз. Когда windbg стартует новый процесс он его стартует сразу суспендед


GN>Извините, не вижу смысла компилировать код с (намеренными?) ошибками (про которые написано в MSDN).
Отличная отмазка. Ошибка в первом фрагменте была изза того что код я сразу запостил без тега [code] и глупые графические смайлики сожрали все После чего просто не заметил пропущенного в исправленном варианте.

GN>Может быть следует убрать в треде printf() ?
В первых двух вариантах — не поможет. В третьем — поможет, но в третьем варианте в нем вся фича.

Вы флеймер, я с флеймерами разговоров не веду

А>В общем-то да, только как ты вытесняющую многозадачность без этой ошибки эволюции сделаешь
Многозадачностью и запуском/остановок в любом месте userspace кода должно заниматься ядро. А не другой юзерспейс код.
Почему — см http://www.rsdn.ru/Forum/Message.aspx?mid=2103250&only=1

Автор: apple-antonovka
Дата: 11.09.06

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

А>>В общем-то да, только как ты вытесняющую многозадачность без этой ошибки эволюции сделаешь
AA>Многозадачностью и запуском/остановок в любом месте userspace кода должно заниматься ядро. А не другой юзерспейс код.
AA>Почему — см http://www.rsdn.ru/Forum/Message.aspx?mid=2103250&only=1

Автор: apple-antonovka
Дата: 11.09.06

Да я и не спорю.
Просто не стоит так вот обобщенно говорить об "ошибке эволюции".

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

GN>>Давайте не будем обобщать. Во-первых, процесс в виндовсе не является исполняемой сущностью, а во-вторых никто не запрещает сделать поток-debigger в адресном пространстве отлаживаемого процесса. В MSDN про это прямо написано.
AA>Причем тут это?

Напомню ход обсуждения:
GN>>>>Без SuspendThread некоторые вещи не возможны в принципе (например — вменяемый отладчик)
AA>>>Вот не надо, отладчик — это отдельный процесс
GN>>Прям таки обязательно — процесс? Вот цитата из MSDN о SuspendThread:
GN>>

To avoid this situation, a thread within an application that is not a debugger should signal the other thread to suspend itself.

AA>Дебаггер отдельные процесс, не имеющий в юзерспейсе никаких синхронизированных объектов с тем кого он дебагит.

AA>(Признак флеймера — использование общеизвестных истин в качестве "доказательств", тогда как они никакой логической связи к этому не имеют)


Пожалуйста, не подменяйте понятия. Я всего лишь настойчиво пытаюсь повторить общеизвестную истину "дебаггер — не обязательно отдельный процесс", которую Вы старательно игнорируете Моё "во-первых" написано для того, что бы мы тут еще и процессы не начали синхронизировать.

AA>>>Поток в удаленном процессе создает windbg.

GN>>Можно указать этот дополнительный тред на картинке:
GN>>
GN>>?
AA>use Attach to active process плз.

О, спасибо! Точно, при аттаче создает дополнительный тред. И 5 раз сработал breakpoint на SuspendThread в процессе WinDbg

AA>Когда windbg стартует новый процесс он его стартует сразу суспендед

Это не так. WinDbg вызывает CreateProcessW с параметром dwCreationFlags == 0. После этого происходит вызов SuspendThread с хендлом != -2 (эту информацию я не придумал, а посмотрел в отладчике).

Нет необходимости создавать процесс и усыплённым тредом (см. MSDN о CREATE_PROCESS_DEBUG_EVENT)

Тепрь о том, зачем отладчику нужно усыплять треды. Это нужно никак не для замены "генерации исключения (банальный int 3)". Это нужно, что бы усыпить остальные треды, когда один вызвал debug event. Про это есть в MSDN (см. About Basic Debugging)

Writing the Debugger's Main Loop
The debugger uses the WaitForDebugEvent function at the beginning of its main loop. This function blocks the debugger until a debugging event occurs. When the debugging event occurs, the system suspends all threads in the process being debugged and notifies the debugger of the event.

GN>>Извините, не вижу смысла компилировать код с (намеренными?) ошибками (про которые написано в MSDN).
AA>Отличная отмазка. Ошибка в первом фрагменте была изза того что код я сразу запостил без тега [code] и глупые графические смайлики сожрали все После чего просто не заметил пропущенного в исправленном варианте.

Я не имел ввиду какие-либо опечатки.

GN>>Может быть следует убрать в треде printf() ?
AA>В первых двух вариантах — не поможет. В третьем — поможет, но в третьем варианте в нем вся фича.

Фича??? Это прямое нарушение документации:

Calling SuspendThread on a thread that owns a synchronization object, such as a mutex or critical section, can lead to a deadlock if the calling thread tries to obtain a synchronization object owned by a suspended thread.

Поскольку printf использует общий ресурс, он обязательно скрывает механизмы синхронизаци. Получили что и хотели. То же и с malloc... да любой пример приведите — он будет нарушать этот пункт.

AA>Вы флеймер, я с флеймерами разговоров не веду

Угу. Защищаю "священную идею" — SuspendThread, ResumeThread, TerminateThread и отчасти ExitThread/_exitthread — НЕ чистое зло и ошибка эволюции.

Но ничего не пытаюсь Вам доказать. Хочу лишь показать другим, что примеры о вреде SuspendThread похожи вот на что:

int main()
{
  int * p = 0;
  *p++; // вывод: указатели - вселенское зло.
}

Да, вывод — это правда о указателях. Но не вся правда.