Что это значит: «Дочерний процесс может наследовать дескриптор»? - PullRequest
9 голосов
/ 11 января 2010

Есть несколько объектов Win32, которые в соответствии с SDK могут быть «унаследованы» дочерним процессам, созданным данным процессом.(События, мьютексы, каналы, ...)

Что это на самом деле означает?

Допустим, у меня есть именованный объект события, созданный с помощью CreateEvent, один раз с bInheritHandle == trueи в другой раз == false.

Теперь я запускаю дочерний процесс.Как эти два дескриптора события влияют на дочерний процесс?В каких сценариях они отличаются?

Ответы [ 3 ]

14 голосов
/ 11 января 2010

Если вы создаете / открываете объект и допускаете наследование этого дескриптора, дочерние процессы, которым разрешено наследовать дескрипторы (например, вы можете указать bInheritHandles = TRUE для CreateProcess), будут иметь копии этих дескрипторов. Эти унаследованные дескрипторы будут иметь те же значения дескриптора, что и родительские дескрипторы. Так, например:

  • CreateEvent возвращает дескриптор объекта события, дескриптор 0x1234.
  • Вы разрешаете наследовать этот дескриптор.
  • Вы создаете дочерний процесс, который наследует ваши дескрипторы.
  • Этот дочерний процесс теперь может использовать дескриптор 0x1234 без необходимости вызова CreateEvent или OpenEvent. Например, вы можете передать значение дескриптора в командной строке дочернего процесса.

Это полезно для безымянных объектов - поскольку они безымянные, другие процессы не могут их открыть. Используя наследование дескрипторов, дочерние процессы могут получить дескрипторы для неназванных объектов, если вы хотите, чтобы они.

2 голосов
/ 28 января 2015

Один момент, который не был сделан в существующих ответах, заключается в том, что разрешение дочернему процессу наследовать дескрипторы влияет не только на дочерний процесс; это также может повлиять на время жизни объекта, к которому относятся дескрипторы. Если родительский процесс завершается, дескрипторы дочернего процесса сохранят объект живым.

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

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

По этой причине передовой практикой является:

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

1 голос
/ 11 января 2010

Если вы создаете событие и позволяете дескриптору наследоваться дочерними процессами, тогда дочерний процесс может использовать дескриптор точно такого же объекта, созданного родительским процессом. Это можно использовать таким образом, когда дочерний элемент использует дескриптор события, чтобы сигнализировать родителю о завершении задачи (есть много других применений для наследуемых дескрипторов объекта события).

EDIT: Удалена дезинформация.

...