summaryrefslogtreecommitdiff
path: root/contrib/stats
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2017-09-05 08:14:53 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-09-06 17:19:53 +0900
commit6b935066960d19713d85e7bbebd442dd8d35e0c6 (patch)
treee72c5a9a62f97ba98e106d65b771b3717758118a /contrib/stats
parenttempfile: factor out deactivation (diff)
downloadtgif-6b935066960d19713d85e7bbebd442dd8d35e0c6.tar.xz
tempfile: robustify cleanup handler
We may call remove_tempfiles() from an atexit handler, or from a signal handler. In the latter case we must take care to avoid functions which may deadlock if the process is in an unknown state, including looking at any stdio handles (which may be in the middle of doing I/O and locked) or calling malloc() or free(). The current implementation calls delete_tempfile(). We unset the tempfile's stdio handle (if any) to avoid deadlocking there. But delete_tempfile() still calls unlink_or_warn(), which can deadlock writing to stderr if the unlink fails. Since delete_tempfile() isn't very long, let's just open-code our own simple conservative version of the same thing. Notably: 1. The "skip_fclose" flag is now called "in_signal_handler", because it should inform more decisions than just the fclose handling. 2. We can replace close_tempfile() with just close(fd). That skips the fclose() question altogether. This is fine for the atexit() case, too; there's no point flushing data to a file which we're about to delete anyway. 3. We can choose between unlink/unlink_or_warn based on whether it's safe to use stderr. 4. We can replace the deactivate_tempfile() call with a simple setting of the active flag. There's no need to do any further cleanup since we know the program is exiting. And even though the current deactivation code is safe in a signal handler, this frees us up in future patches to make non-signal deactivation more complicated (e.g., by freeing resources). 5. There's no need to remove items from the tempfile_list. The "active" flag is the ultimate answer to whether an entry has been handled or not. Manipulating the list just introduces more chance of recursive signals stomping on each other, and the whole list will go away when the program exits anyway. Less is more. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'contrib/stats')
0 files changed, 0 insertions, 0 deletions