[ccache] ccache interrupt handling bug

[Tom Lane]

"Nadav Har'El" <nyh at cloudius-systems.com> writes:
> First of all, thanks. This indeed fixes the bug, and is exactly the first
> patch I tried to fix it this problem.

> I want to explain, though, why I ended up sending a different patch for
> this problem - a 4-line patch instead of this one-liner. The explanation is
> not very important, and I should probably have done this earlier, but
> perhaps someone would find it interesting.

> When the user types ^C, the operating system sends SIGINT to all processes
> belonging to the terminal's process group - and in particular it sends
> SIGINT to *both* the child compiler and ccache, separately.

> Your patch makes ccache exit as soon as it gets the SIGINT - but the child
> compiler might still be running for a while longer. This will usually be
> fine, but I thought the user can be surprised if he sees ccache (which he
> considers to be the compiler) exit, but "ps" shows the compiler is still
> running. This would be especially annoying if some hypothetical compiler
> trapped SIGINT deliberately, and continued to run long after ccache exits.

Actually, that's a bug not just a cosmetic problem, because it introduces
a race condition.  Consider this sequence of events:

* make launches "ccache gcc -o test.o test.c"
* user types control-C
* ccache receives SIGINT and exits
* make does unlink("test.o") to clean up after failed compile step, which
  it thinks is done
* gcc creates test.o
* gcc receives SIGINT and exits

We're left with a probably-broken test.o in the filesystem, despite
make's attempt to clean up.  Now, the window for this is pretty narrow,
but I think it could happen: I don't believe that sending signals to
multiple processes is atomic in most kernels.

You really don't want ccache to exit until after all externally-observable
things have stopped happening.  (I recently fixed a somewhat related bug
in Postgres :-(, which is why this caught my eye.)

			regards, tom lane