What does it mean: "A child-process can inherit the handle"?

Question

There are some Win32 objects which according to the SDK can be "inherited" to the child-processes created by the given process. (Events, mutexes, pipes, ...)

What does that actually mean?

Let's say I have a named event object, created with CreateEvent, one time with bInheritHandle == true, and another time == false.

Now I start a child process. How do those two event handles affect the child process. In which scenarios do they differ?

Answer 1

If you create an event, and allow the handle to be inherited by child processes, then the child process can use the handle to the exact same object created by the parent. This can be used in a way where a child uses an event handle to signal to the parent when a task has been completed (there are many other uses for inheritable event object handles).

EDIT: Removed disinformation.

Answer 2

If you create/open an object and allow that handle to be inherited, child processes which are allowed to inherit handles (e.g. you can specify bInheritHandles = TRUE for CreateProcess) will have copies of those handles. Those inherited handles will have the same handle values as the parent handles. So for example:

• CreateEvent returns a handle to an event object, handle is 0x1234.
• You allow that handle to be inherited.
• You create a child process that inherits your handles.
• That child process can now use handle 0x1234 without having to call CreateEvent or OpenEvent. You could for example pass the handle value in the command line of the child process.

This is useful for unnamed objects - since they're unnamed, other processes can't open them. Using handle inheritance child processes can obtain handles to unnamed objects if you want them to.