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

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

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

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

tlp>>>http://msdn.microsoft.com/en-us/library/windows/desktop/ms684161(v=vs.85).aspx

X>>Я же написал что Jobы не вариант.

tlp>http://msdn.microsoft.com/en-us/library/windows/desktop/hh448388(v=vs.85).aspx

Вложенные Jobы ведь только в windows 8

O>>>>Навскидку несколько решений, но все топорные:
O>>>>1) Метод влоб. Toolhelp'ом периодически перечислять все живые процессы, проверяя их парентов. Метод требует _не закрывания_ хэндла на процесс A до окончания всей спецоперации, в противном случае его PID может реюзнуться и выйдет конфуз.
X>>>Как вариант, но думал есть варианты попроще
O>>У него есть и большой недостаток — если как вы ниже написали процессы B и C могут порождать правнуков, которых тоже нужно ждать — то этот вариант — не вариант.
X>Почему не вариант? Я же знаю PID процессов B и C, почему тогда к правнукам нельзя применить тот же метод?
Потому что между интервалами проверок А и Б могут упасть с трубы B и C могут успеть запуститься, запустить правнуков и издохнуть, и к следующей проверке останутся только правнуки, которых вы упустите.

O>>>>..подумаю, может еще чего добавлю, если конечно методы такого рода представляют интерес
X>>>Наверное можно еще сделать перехват CreateProcess и если эта функция вызывается в интересующем процессе, то передавать PID этого процесса ожидающей программе.
O>>Сделать перехват, и сделать перехват, работающий стабильно на различных системах — это проблемы разных порядков. Особенно если это перехват CreateProcess'а.
X>А чем перехват CreateProcess отличается от перехвата другой функции?
Тем что его чаще все всего и перехватывают. А в хуках самая большая сложность — дружно сосуществовать с другими хуками, некоторые из которых бывают весьма ущербны.
Кстати в качестве альтернативы хуков можно рассмотреть ключик App_InitDlls — но у этого способа куча своих недостатков — чтобы прописаться/выписаться нужны админские права, в новых виндах появляются танцы с бубном с подписями и вообще функционированием этого ключа.

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

X>Не вариант, я же не в курсе, что будут за процессы B и C и будут ли они вообще

Будут ли вообще — не проблема, а насчет первого уточни. Выходит, A может запускать неизвестно из какого списка берущиеся B и C ? Или все же список кандидатов известен ? EXE-шники все же не зарождаются сами...

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

X>>Не вариант, я же не в курсе, что будут за процессы B и C и будут ли они вообще

PD>Будут ли вообще — не проблема, а насчет первого уточни. Выходит, A может запускать неизвестно из какого списка берущиеся B и C ? Или все же список кандидатов известен ? EXE-шники все же не зарождаются сами...

я так понял, процесс А — может быть любым(например, пользователь выбрал)?

Хотелось бы узнать у автора, какова цель? А то, может быть, решение совсем другое нужно.

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

CEM>Здравствуйте, Pavel Dvorkin, Вы писали:

X>>>Не вариант, я же не в курсе, что будут за процессы B и C и будут ли они вообще

PD>>Будут ли вообще — не проблема, а насчет первого уточни. Выходит, A может запускать неизвестно из какого списка берущиеся B и C ? Или все же список кандидатов известен ? EXE-шники все же не зарождаются сами...

CEM>я так понял, процесс А — может быть любым(например, пользователь выбрал)?

CEM>Хотелось бы узнать у автора, какова цель? А то, может быть, решение совсем другое нужно.

Процесс A действительно может быть любым, об остальных процессах программа вообще ничего не знает. Их в принципе может и не быть.
А процессы B и C просто для примера, тем более их действительно может создать сам процесс A (например скопировать из своего оверлея или распаковать архив во временную папку).
Как пример, посмотрите как запускается ProcessExplorer на x64 системах.
А задача: дождаться окончания определенной операции, начатой при запуске процесса А, а заканчивающейся при завершении процесса А и всех процессов, порожденных процессом А и его внуками (правнуками и т.д.).

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

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

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

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

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

tlp>>>>http://msdn.microsoft.com/en-us/library/windows/desktop/ms684161(v=vs.85).aspx

X>>>Я же написал что Jobы не вариант.

tlp>>http://msdn.microsoft.com/en-us/library/windows/desktop/hh448388(v=vs.85).aspx

X>Вложенные Jobы ведь только в windows 8

ииии?

windows 8 уже 2 года как вышла Или досточтимый сэр собирается поддерживать официально убитую Windows XP или вот-вот заканчивающую цикл поддержки Windows 7?

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

X>>Вложенные Jobы ведь только в windows 8

tlp>ииии?

tlp>windows 8 уже 2 года как вышла Или досточтимый сэр собирается поддерживать официально убитую Windows XP или вот-вот заканчивающую цикл поддержки Windows 7?

я уже рассказывал историю, как пошёл продвигаться на одном очень крупном архиве, завёл ветку на форуме, написал текст, стал общаться с народом, в том числе, кто чем пользуется и почему. И в очередной вопрос "а чем оно хорошо?", собеседник мне ответил: "мне нравится, и на моей 95-й не тормозит" — "у тебя 95-я винда?!" — "да"

...моя программа на 95-й винде точно не работала, возразить мне было нечего...

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

X>>>>Не вариант, я же не в курсе, что будут за процессы B и C и будут ли они вообще

PD>>>Будут ли вообще — не проблема, а насчет первого уточни. Выходит, A может запускать неизвестно из какого списка берущиеся B и C ? Или все же список кандидатов известен ? EXE-шники все же не зарождаются сами...

CEM>>я так понял, процесс А — может быть любым(например, пользователь выбрал)?

CEM>>Хотелось бы узнать у автора, какова цель? А то, может быть, решение совсем другое нужно.

X>Процесс A действительно может быть любым, об остальных процессах программа вообще ничего не знает. Их в принципе может и не быть.
X>А процессы B и C просто для примера, тем более их действительно может создать сам процесс A (например скопировать из своего оверлея или распаковать архив во временную папку).
X>Как пример, посмотрите как запускается ProcessExplorer на x64 системах.
X>А задача: дождаться окончания определенной операции, начатой при запуске процесса А, а заканчивающейся при завершении процесса А и всех процессов, порожденных процессом А и его внуками (правнуками и т.д.).

А какова цель всего этого, если не секрет? Зачем дожидаться окончания всех дочерних процессов?

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

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

X>>>>>Не вариант, я же не в курсе, что будут за процессы B и C и будут ли они вообще

PD>>>>Будут ли вообще — не проблема, а насчет первого уточни. Выходит, A может запускать неизвестно из какого списка берущиеся B и C ? Или все же список кандидатов известен ? EXE-шники все же не зарождаются сами...

CEM>>>я так понял, процесс А — может быть любым(например, пользователь выбрал)?

CEM>>>Хотелось бы узнать у автора, какова цель? А то, может быть, решение совсем другое нужно.

X>>Процесс A действительно может быть любым, об остальных процессах программа вообще ничего не знает. Их в принципе может и не быть.
X>>А процессы B и C просто для примера, тем более их действительно может создать сам процесс A (например скопировать из своего оверлея или распаковать архив во временную папку).
X>>Как пример, посмотрите как запускается ProcessExplorer на x64 системах.
X>>А задача: дождаться окончания определенной операции, начатой при запуске процесса А, а заканчивающейся при завершении процесса А и всех процессов, порожденных процессом А и его внуками (правнуками и т.д.).

CEM>А какова цель всего этого, если не секрет? Зачем дожидаться окончания всех дочерних процессов?
Для синхронизации задач. Например задача 2 должна выполниться только строго после задачи 1, а задача 1 в свою очередь состоит из того, что процесс А должен выполнить свою работу.
Примеров можно множество придумать.

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


CEM>я уже рассказывал историю, как пошёл продвигаться на одном очень крупном архиве, завёл ветку на форуме, написал текст, стал общаться с народом, в том числе, кто чем пользуется и почему. И в очередной вопрос "а чем оно хорошо?", собеседник мне ответил: "мне нравится, и на моей 95-й не тормозит" — "у тебя 95-я винда?!" — "да"

CEM>...моя программа на 95-й винде точно не работала, возразить мне было нечего...

Да понятно, конечно. ТС просто нигде не указал, какую ОС имеет в виду и пишет ли он шаровару, которая должна работать на утюге Windows NT 3.51/windows phone/windows CE.

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

CEM>>А какова цель всего этого, если не секрет? Зачем дожидаться окончания всех дочерних процессов?
X>Для синхронизации задач. Например задача 2 должна выполниться только строго после задачи 1, а задача 1 в свою очередь состоит из того, что процесс А должен выполнить свою работу.
X>Примеров можно множество придумать.

Всё равно непонятно. Почему задача 2 ждёт задачу 1? Моя гипотеза: общие системные ресурсы (файлы, сетевые порты и прочее), тогда проще следить за доступом к этим ресурсам. Потому что кроме процессов, можно ещё CreateRemoteThread кому-нибудь сделать.
>>>А, и тут сразу мысль ещё: при старте процесса 1 вставлять ему Mutex, а 2 сидит и ждёт этот Mutex. Плюс перехват CreateProcess и далее по рекурсии. Без перехвата можно успеть насоздавать детей от детей между снимками, а родителей перебить, так что потом будет неясно, кто кому ребёнок.