A customer was having a problem with named pipes. <\/p>\n
Our main process creates a named pipe with
ACCESS_INBOUND<\/code> and passes the write handle to the child process. The main process keeps reading from the pipe until it getsERROR_PIPE_BROKEN<\/code>. We expect that when the child process terminates, the main process will get theERROR_PIPE_BROKEN<\/code> error. However, we are finding that sometimes the main proecss doesn’t get theERROR_PIPE_BROKEN<\/code> error, even though the child process has definitely terminated. Are there cases where the process with the write end of the pipe terminates, but the read doesn’t error out withERROR_PIPE_BROKEN<\/code>? <\/p><\/blockquote>\nYou won’t get
ERROR_PIPE_BROKEN<\/code> until all the write handles are closed. One common reason why you don’t get the error is that there’s still a write handle open in the parent process<\/a>. Another possibility is that the child process launched a subprocess which inherited the write handle, or more generally, the handle got duplicated into another process by some means. <\/p>\nThe customer wrote back. <\/p>\n
Thanks. That is indeed the issue. The main process spawns many child processes simultaneously, so depending on race conditions, the write handle for one pipe could inadvertently be inherited by an unrelated child process. We could explicitly serialize our
CreateProcess<\/code> calls, but is there another way to specify that a child process should inherit only certain handles and not others? <\/p><\/blockquote>\n