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?
An inherited handle refers to the same object in the child process as it does in the parent process. It also has the same value and access privileges. Therefore, when one process changes the state of the object, the change affects both processes.
On most systems, the child executes first. This is to avoid the overhead that comes with copy on write, since the parent does not write to the address space. There is no "X executes before Y" relation between parent and child processes (as there is with normal functions where "callee executes before the caller).
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
.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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With