[PATCH v2 1/5] t/helper/test-write-cache: clean up lock-handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Die in case writing the index fails, so that the caller can notice
(instead of, say, being impressed by how performant the writing is).

While at it, note that after opening a lock with `LOCK_DIE_ON_ERROR`, we
do not need to worry about whether we succeeded. Also, we can move the
`struct lock_file` into the function and drop the staticness. (Placing
`struct lock_file`s on the stack used to be a bad idea, because the
temp- and lockfile-machinery would keep a pointer into the struct. But
after 076aa2cbd (tempfile: auto-allocate tempfiles on heap, 2017-09-05),
we can safely have lockfiles on the stack.)

Signed-off-by: Martin Ågren <martin.agren@xxxxxxxxx>
---
 t/helper/test-write-cache.c | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/t/helper/test-write-cache.c b/t/helper/test-write-cache.c
index 017dc30380..8837717d36 100644
--- a/t/helper/test-write-cache.c
+++ b/t/helper/test-write-cache.c
@@ -2,22 +2,18 @@
 #include "cache.h"
 #include "lockfile.h"
 
-static struct lock_file index_lock;
-
 int cmd__write_cache(int argc, const char **argv)
 {
-	int i, cnt = 1, lockfd;
+	struct lock_file index_lock = LOCK_INIT;
+	int i, cnt = 1;
 	if (argc == 2)
 		cnt = strtol(argv[1], NULL, 0);
 	setup_git_directory();
 	read_cache();
 	for (i = 0; i < cnt; i++) {
-		lockfd = hold_locked_index(&index_lock, LOCK_DIE_ON_ERROR);
-		if (0 <= lockfd) {
-			write_locked_index(&the_index, &index_lock, COMMIT_LOCK);
-		} else {
-			rollback_lock_file(&index_lock);
-		}
+		hold_locked_index(&index_lock, LOCK_DIE_ON_ERROR);
+		if (write_locked_index(&the_index, &index_lock, COMMIT_LOCK))
+			die("unable to write index file");
 	}
 
 	return 0;
-- 
2.17.0.411.g9fd64c8e46




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux