Tom Lane <t...@sss.pgh.pa.us> wrote: > > 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.
Yes, sounds like a race condition that could happen. I just pushed this change as a fix: https://git.samba.org/?p=ccache.git;a=commitdiff;h=4fdb9580fedac9669508bef0837f46f1e9310e24. Opinions on it are welcome. [...] I wonder whether it's sane to do "clean_up_pending_tmp_files();" when > gcc is still on the loose. clean_up_pending_tmp_files only deletes temporary files used to catch the compiler's stdout and stderr, so that shouldn't be a problem. -- Joel _______________________________________________ ccache mailing list email@example.com https://lists.samba.org/mailman/listinfo/ccache