undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

tempfile: update comment describing state transitions

Browse Source 
Back when 1a9d15db25 (tempfile: a new module for handling temporary
files, 2015-08-10) added this comment, tempfile structs were held in
memory for the life of a process, and there were various guarantees
about which fields were valid in which states.

Since 422a21c6a0 (tempfile: remove deactivated list entries, 2017-09-05)
and 076aa2cbda (tempfile: auto-allocate tempfiles on heap, 2017-09-05),
the flow is quite different: objects come and go from the list, and
inactive ones are deallocated. And the previous commit removed the
"active" flag from the struct entirely.

Let's bring the comment up to date with the current code.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Jeff King 2022-08-30 15:46:01 -04:00 committed by Junio C Hamano
parent 77a42b3b84
commit 320fa579ec
1 changed files with 5 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
tempfile.c
View File

@ -14,16 +14,14 @@
* *
* The possible states of a `tempfile` object are as follows: * The possible states of a `tempfile` object are as follows:
* *
* - Uninitialized. In this state the object's `on_list` field must be * - Inactive/unallocated. The only way to get a tempfile is via a creation
* zero but the rest of its contents need not be initialized. As * function like create_tempfile(). Once allocated, the tempfile is on the
* soon as the object is used in any way, it is irrevocably * global tempfile_list and considered active.
* registered in `tempfile_list`, and `on_list` is set.
* *
* - Active, file open (after `create_tempfile()` or * - Active, file open (after `create_tempfile()` or
* `reopen_tempfile()`). In this state: * `reopen_tempfile()`). In this state:
* *
* - the temporary file exists * - the temporary file exists
* - `active` is set
* - `filename` holds the filename of the temporary file * - `filename` holds the filename of the temporary file
* - `fd` holds a file descriptor open for writing to it * - `fd` holds a file descriptor open for writing to it
* - `fp` holds a pointer to an open `FILE` object if and only if * - `fp` holds a pointer to an open `FILE` object if and only if
@ -35,14 +33,8 @@
* `fd` is -1, and `fp` is `NULL`. * `fd` is -1, and `fp` is `NULL`.
* *
* - Inactive (after `delete_tempfile()`, `rename_tempfile()`, or a * - Inactive (after `delete_tempfile()`, `rename_tempfile()`, or a
* failed attempt to create a temporary file). In this state: * failed attempt to create a temporary file). The struct is removed from
* * the global tempfile_list and deallocated.
* - `active` is unset
* - `filename` is empty (usually, though there are transitory
* states in which this condition doesn't hold). Client code should
* *not* rely on the filename being empty in this state.
* - `fd` is -1 and `fp` is `NULL`
* - the object is removed from `tempfile_list` (but could be used again)
* *
* A temporary file is owned by the process that created it. The * A temporary file is owned by the process that created it. The
* `tempfile` has an `owner` field that records the owner's PID. This * `tempfile` has an `owner` field that records the owner's PID. This