Что это значит:"дочерний процесс может наследовать дескриптор"?

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

что это значит?

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

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

3 ответов


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

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

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


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

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

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

по этой причине, рекомендуется кому:

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


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

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