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

There are some Win32 objects which according to the SDK can be "inherited" to the child-processes created by the given process. (Event开发者_StackOverflow中文版s, 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?

---

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.

---

One point which has not been made in the existing answers is that allowing a child process to inherit handles doesn't only affect the child process; it may also affect the lifetime of the object to which the handles refer. If the parent process exits, the handles in the child process will keep the object alive.

When allowing a child process to inherit handles you must consider whether it will result in an object living longer than it should; for example, some applications only want to allow one instance to run at a time, and might do that by creating an event object with a given name and seeing whether it already exists. If they create a child process which inherits that event object, and outlives the parent, it could result in a false positive.

More commonly, an inherited handle to a file may result in the file remaining in use (and hence inaccessible) longer than it should have.

For this reason, best practice is to:

• Make all handles as non-inheritable unless they specifically need to be inherited.

• If a subprocess doesn't need to inherit handles, pass FALSE for bInheritHandles.

• If a subprocess does need to inherit handles, only allow it to inherit those specific handles that are needed.

On the other hand, this can occasionally be useful; for example, if you want the child process to count as an instance of the parent process, or for a file to remain inaccessible until the child has exited. Another trick is to have a child inherit a handle to a named object and then use the existence or non-existence of the object to determine whether the child is still alive, without having to pass around a process handle or process ID.

---

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.