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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Как известно, при создании нового процесса CreateProcess возвращает handle, который переходит в состояние signaled при завершении созданного процесса. А есть ли возможность, создав в этом новом процессе еще один процесс ("внук" первого процесса), как-то передать ему по наследству эту самую возможность ожидания завершения этого "внука" процессом-"дедом"? То есть, чтобы исходный процесс ("дед") после завершения процесса-"сына" продолжал ждать, пока не завершится процесс-"внук", сам ничего не зная об их внутренних взаимоотношениях?

Здесь, как мне кажется, уместно было бы использовать Job-объекты. Ну то есть при создании нового процесса поместить его в Job и
далее через SetInformationJobObject с кодом JobObjectAssociateCompletionPortInformation подписаться на события.
Когда все процессы Job-а будут завершены, прилетит уведомление JOB_OBJECT_MSG_ACTIVE_PROCESS_ZERO.

Здесь, правда, есть нюансы. Например, на системах до Windows 8, если "сын" захочет тоже поместить "внука" в новый Job-объект, то у
него ничего не выйдет (потому что вложенные Job-ы там не поддерживаются). Также возможны проблемы, если кто-то попытается вырваться
из Job-а, я про флаг CREATE_BREAKAWAY_FROM_JOB и т.п. Но в целом, вполне себе решение.

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

O>уместно было бы использовать Job-объекты.

Когда исходный процесс — наш собственный, эту синхронизацию нетрудно сделать разными способами, но мне хочется сделать и для случая, когда исходный процесс — чужой. Например, такая проблема возникает у любого несистемного деинсталлятора, которому нужно в итоге удалить и себя, и собственный каталог. Это делается через копирование себя куда-нибудь в TEMP и запуском оттуда, но, при завершении первого экземпляра деинсталлятора, запустивший его процесс получает сигнал через handle, и все остальное приходится завершать асинхронно, а это некрасиво.

Здравствуйте, Евгений Музыченко, Вы писали:


ЕМ>Когда исходный процесс — наш собственный, эту синхронизацию нетрудно сделать разными способами, но мне хочется сделать и для случая, когда исходный процесс — чужой. Например, такая проблема возникает у любого несистемного деинсталлятора, которому нужно в итоге удалить и себя, и собственный каталог. Это делается через копирование себя куда-нибудь в TEMP и запуском оттуда, но, при завершении первого экземпляра деинсталлятора, запустивший его процесс получает сигнал через handle, и все остальное приходится завершать асинхронно, а это некрасиво.

Чище выглядела бы попытка unmap бинарника при живом процессе. Например, пусть "сын" будет rundll32-hosted процессом, тогда такое состояние, когда бинарник (в этом случае DLL) уже выгружен, а процесс — ещё работает, было бы легальным. Тогда в процессе rundll32 худалять бинарник будет хук на собственный ExitProcess, откуда вызывается другая DLL из того самого TEMP, а то и код не спроецированный, а прямо помещённый в VirtualAlloc памяти.

Не знаю, насколько вышеописанная схема жизнеспособна, но кажется, что подменить объект ожидания у "деда" не меняя его вообще невозможно.

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

AG>кажется, что подменить объект ожидания у "деда" не меняя его вообще невозможно.

А интересно, в унихах, если несколько процессов соединены pipe'ами, все эти процессы живут до завершения последнего из них? Это ж примерно то же самое.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Как известно, при создании нового процесса CreateProcess возвращает handle, который переходит в состояние signaled при завершении созданного процесса. А есть ли возможность, создав в этом новом процессе еще один процесс ("внук" первого процесса), как-то передать ему по наследству эту самую возможность ожидания завершения этого "внука" процессом-"дедом"? То есть, чтобы исходный процесс ("дед") после завершения процесса-"сына" продолжал ждать, пока не завершится процесс-"внук", сам ничего не зная об их внутренних взаимоотношениях?

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

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

D>А тупо взять список процессов, найти внуков, открыть процессы и получить хендлы не катит? Тогда дед будет иметь хендлы всего дерева процессов.

ЕМ>>То есть, чтобы исходный процесс ("дед") после завершения процесса-"сына" продолжал ждать, пока не завершится процесс-"внук", сам ничего не зная об их внутренних взаимоотношениях?

ЕМ>Когда исходный процесс — наш собственный, эту синхронизацию нетрудно сделать разными способами, но мне хочется сделать и для случая, когда исходный процесс — чужой.
Не очень понятно, что именно возможно сделать. Например подменить дочерник процесс деда — возможно? На такой, который запустит оригинальный процесс в джобе и выйдет сам лишь когда джоб опустеет.

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

O>Например подменить дочерник процесс деда — возможно? На такой, который запустит оригинальный процесс в джобе и выйдет сам лишь когда джоб опустеет.

Основная проблема — это различные ресурсы (каталог процесса, загруженные в него DLL, файлы/устройства/ключи, которые они открывают и т.п.), связанные с дочерним процессом. Не будь всего этого, не потребовалось бы и "внучатого".