Is it really necessary to close the unused end of the pipe in a process

According to the man page for getdtablesize

Each process has a fixed size descriptor table, which is guaranteed to have at least 20 slots.

Each pipe uses two entries in the descriptor table. Closing the unneeded end of the pipe frees up one of those descriptors. So, if you were unfortunate enough to be on a system where each process is limited to 20 descriptors, you would be highly motivated free up unneeded file descriptors.


Pipes are destined to be used as unidirectional communication channels. Closing them is a good practice allowing to avoid some mess in sent messages. Writer's descriptor should be closed for reader and vice versa.


Here's the problem if you don't. In your example, the parent creates a pipe for writing to the child. It then forks the child but does not close its own read descriptor. This means that there are still two read descriptors on the pipe.

If the child had the only one and it closed it (for example, by exiting), the parent would get a SIGPIPE signal or, if that was masked, an error on writing to the pipe.

However, there is a second read descriptor on the pipe (the parent's). Now, if the child exits, the pipe will remain open. The parent can continue to write to the pipe until it fills and then the next write will block (or return without writing if non-blocking).

Thus, by not closing the parent's read descriptor, the parent cannot detect that the child has closed its descriptor.

Tags:

Unix

C

Pipe