I have a use case, albeit one from a toy program (actually a homework assignment).

The assignment was to write a program that would take two arguments, which are the names of executables. It would start them up, using fork and exec (or e.g. execve), with the stdout of the first program writing to one end of a pipe that was read as stdin of the second program.

Example usage: ./mypipeprogram ./program1 ./program2 should give results identical(ish) to ./program1 | ./program2.

I wanted my program to be as close to bulletproof as I could get it, and that meant handling all the errors that I could, as gracefully as I could.

You'll have to forgive me, as I don't think I have the source anymore, so this is from memory.

One of the kinds of errors I had to try to handle was the case where one of the programs listed couldn't be exec'd, but the other could. In that case, the process that couldn't exec could kill the other process, so it wouldn't hang forever, or anything like that.

In hindsight, probably not the best idea, because closing the pipe should have worked fine.

Still, going one way (I think it was the first process, the output one), I could catch this, and instead kill the other process before it even tried to exec the other program.

What I did was open another pipe, and fnctl it with FD_CLOEXEC, relying on POSIX saying that "the file shall be closed upon successful execution of one of the exec functions."

Then the second process would prepare to exec, read from that pipe, and when it was closed, it would know the first process successfully exec'd, so it could go ahead. If the first process's exec failed, the pipe would still be open, so the second process would still be blocked on the read, and the first process could kill it.

TL;DR

I used FD_CLOEXEC on a pipe to allow one process to wait for a second process to successfully exec, or get killed by the second process if the exec failed.