Убивать дочерние процессы при смерти родительского

Тема в разделе "WASM.WIN32", создана пользователем srm, 22 июн 2011.

  1. srm

    srm New Member

    Публикаций:
    0
    Регистрация:
    14 июн 2011
    Сообщения:
    189
    Здравствуйте.
    Меня интересует есть ли в винде такая функциональность, чтобы при смерти родительского процесса порождённые им дочерние убивались автоматически. Понятно, что эту функциональность можно реализовать - открывать в дочернем процессе родительский и ждать сигнал от него. Но может есть уже готовая функциональность (н-р параметры CreateProcess)?
     
  2. klzlk

    klzlk New Member

    Публикаций:
    0
    Регистрация:
    2 июн 2011
    Сообщения:
    449
    Процесс родитель должен быть отладчиком.

    Сервисы запускающие процессы требуют опционально в аргументах описатель отладочного порта.

    Как решать - трассировать апи и изменять параметры сервиса при вызове стаба или шлюза(ожидаемый вопрос). Это динамически. Но можно и переключить поток на отморфленный код.
     
  3. onSide

    onSide New Member

    Публикаций:
    0
    Регистрация:
    18 июн 2008
    Сообщения:
    476
    А просто OpenProcess->WaitForSingleObject чем не подходит?
     
  4. klzlk

    klzlk New Member

    Публикаций:
    0
    Регистрация:
    2 июн 2011
    Сообщения:
    449
    onSide
    При завершении ждущего потока, обьект на котором происходит ожидание не будет уничтожен - он вообще ничего не узает про это.
     
  5. srm

    srm New Member

    Публикаций:
    0
    Регистрация:
    14 июн 2011
    Сообщения:
    189
    Не нравится то, что в дочернем процессе нужно дополнительный поток создавать (практически бесполезный).
     
  6. klzlk

    klzlk New Member

    Публикаций:
    0
    Регистрация:
    2 июн 2011
    Сообщения:
    449
    srm
    Ожидание на обьекте имеет таймаут. Более того, допустим синхронный выход из ожидания ждущего треда - APC. Короче учите матчасть, иначе описывать придётся всю ось.
     
  7. int2eh

    int2eh Alexander Leevy

    Публикаций:
    0
    Регистрация:
    19 авг 2007
    Сообщения:
    106
    Адрес:
    Москва
    srm
    Почитайте Рихтера про процессы и потоки, плz!
     
  8. onSide

    onSide New Member

    Публикаций:
    0
    Регистрация:
    18 июн 2008
    Сообщения:
    476
    klzlk
    да, но ведь по тз родительский поток не должен завершаться при смерти дочернего.

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

    Partner Павел

    Публикаций:
    0
    Регистрация:
    28 фев 2008
    Сообщения:
    917
    Адрес:
    Los Angeles
    1. Создать job - CreateJobObject
    2. Добавить нужные процессы к job - AssignProcessToJobObject
    3. Убить job - TerminateJobObject. Все ассоциированные процессы также будут убиты.
     
  10. x64

    x64 New Member

    Публикаций:
    0
    Регистрация:
    29 июл 2008
    Сообщения:
    1.370
    Адрес:
    Россия
    Это необязательно.
    Есть флаг JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE:
    Т.е. создаём Job, но не закрываем хендл.
    При завершении процесса хендл будет закрыт автоматически.
    Соответственно, все связанные процессы в Job-е будут автоматически убиты.
     
  11. Partner

    Partner Павел

    Публикаций:
    0
    Регистрация:
    28 фев 2008
    Сообщения:
    917
    Адрес:
    Los Angeles
    Так тоже можно.
     
  12. srm

    srm New Member

    Публикаций:
    0
    Регистрация:
    14 июн 2011
    Сообщения:
    189
    WaitForMultipleObjects можно запускать в цикле и проверять код возврата.
    Может прекратите давать нелепые ответы? Задача вполне ясна.
    нет.

    это понятно. Кто будет вызывать TerminateJobObject? Откуда дочерний процесс узнает о смерти родительского? А родительский при своём завершении вызвать не может, т.к. может завершиться некорректно.

    x64, спасибо за совет. Работает именно так, как и требовалось :))

    P.S. Можно закрывать.