git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Brandon Casey <drafnel@gmail.com>
Cc: "Linus Torvalds" <torvalds@linux-foundation.org>,
	"Brandon Casey" <casey@nrlssc.navy.mil>,
	"Git Mailing List" <git@vger.kernel.org>,
	"Alex Riesen" <raa.lkml@gmail.com>,
	"Kristian Høgsberg" <krh@redhat.com>
Subject: [PATCH 2/2] close_lock_file(): new function in the lockfile API
Date: Wed, 16 Jan 2008 11:05:32 -0800	[thread overview]
Message-ID: <7vejchr3pf.fsf_-_@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0801152006260.944-100000@demand> (Brandon Casey's message of "Tue, 15 Jan 2008 20:11:55 -0600 (CST)")

The lockfile API is a handy way to obtain a file that is cleaned
up if you die().  But sometimes you would need this sequence to
work:

 1. hold_lock_file_for_update() to get a file descriptor for
    writing;

 2. write the contents out, without being able to decide if the
    results should be committed or rolled back;

 3. do something else that makes the decision --- and this
    "something else" needs the lockfile not to have an open file
    descriptor for writing (e.g. Windows do not want a open file
    to be renamed);

 4. call commit_lock_file() or rollback_lock_file() as
    appropriately.

This adds close_lock_file() you can call between step 2 and 3 in
the above sequence.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/technical/api-lockfile.txt |   11 +++++++++--
 cache.h                                  |    2 +-
 lockfile.c                               |    6 ++++++
 3 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/Documentation/technical/api-lockfile.txt b/Documentation/technical/api-lockfile.txt
index 5b1553e..def5f2a 100644
--- a/Documentation/technical/api-lockfile.txt
+++ b/Documentation/technical/api-lockfile.txt
@@ -45,6 +45,11 @@ rollback_lock_file::
 	with an earlier call to `hold_lock_file_for_update()`,
 	close the file descriptor and remove the lockfile.
 
+close_lock_file::
+	Take a pointer to the `struct lock_file` initialized
+	with an earlier call to `hold_lock_file_for_update()`,
+	and close the file descriptor.
+
 Because the structure is used in an `atexit(3)` handler, its
 storage has to stay throughout the life of the program.  It
 cannot be an auto variable allocated on the stack.
@@ -54,8 +59,10 @@ done writing to the file descriptor.  If you do not call either
 and simply `exit(3)` from the program, an `atexit(3)` handler
 will close and remove the lockfile.
 
-You should not close the file descriptor you obtained from
-`hold_lock_file_for_update` function yourself.  The `struct
+If you need to close the file descriptor you obtained from
+`hold_lock_file_for_update` function yourself, do so by calling
+`close_lock_file()`.  You should never call `close(2)` yourself!
+Otherwise the `struct
 lock_file` structure still remembers that the file descriptor
 needs to be closed, and a later call to `commit_lock_file()` or
 `rollback_lock_file()` will result in duplicate calls to
diff --git a/cache.h b/cache.h
index 39331c2..5033b34 100644
--- a/cache.h
+++ b/cache.h
@@ -308,7 +308,7 @@ extern int commit_lock_file(struct lock_file *);
 extern int hold_locked_index(struct lock_file *, int);
 extern int commit_locked_index(struct lock_file *);
 extern void set_alternate_index_output(const char *);
-
+extern void close_lock_file(struct lock_file *);
 extern void rollback_lock_file(struct lock_file *);
 extern int delete_ref(const char *, const unsigned char *sha1);
 
diff --git a/lockfile.c b/lockfile.c
index f45d3ed..e57d850 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -201,3 +201,9 @@ void rollback_lock_file(struct lock_file *lk)
 	}
 	lk->filename[0] = 0;
 }
+
+void close_lock_file(struct lock_file *lk)
+{
+	close(lk->fd);
+	lk->fd = -1;
+}
-- 
1.5.4.rc3.14.g44397

  parent reply	other threads:[~2008-01-16 19:06 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-11 22:11 git-commit fatal: Out of memory? mmap failed: Bad file descriptor Brandon Casey
2008-01-11 22:18 ` Charles Bailey
2008-01-12  4:56   ` Jeff King
2008-01-11 22:19 ` Marco Costalba
2008-01-11 22:47 ` Brandon Casey
2008-01-11 23:48   ` Junio C Hamano
2008-01-12  0:43     ` Brandon Casey
2008-01-12  1:08       ` Junio C Hamano
2008-01-12 20:16   ` Alex Riesen
2008-01-14 23:22     ` Brandon Casey
2008-01-15  2:42 ` Brandon Casey
2008-01-15  5:42   ` Linus Torvalds
2008-01-15 17:26     ` Brandon Casey
2008-01-15 17:36       ` Linus Torvalds
2008-01-15 18:27         ` Brandon Casey
2008-01-15 18:50           ` Linus Torvalds
2008-01-15 19:43             ` Brandon Casey
2008-01-15 20:00               ` Kristian Høgsberg
2008-01-15 20:27                 ` Brandon Casey
2008-01-15 20:39                 ` Brandon Casey
2008-01-15 20:09               ` Linus Torvalds
2008-01-15 20:20                 ` Linus Torvalds
2008-01-15 23:10             ` Junio C Hamano
2008-01-16  1:27               ` Junio C Hamano
2008-01-16  2:11                 ` Brandon Casey
2008-01-16 19:00                   ` [PATCH 1/2] Document lockfile API Junio C Hamano
2008-01-16 19:05                   ` Junio C Hamano [this message]
2008-01-16 20:08                     ` [PATCH 2/2] close_lock_file(): new function in the " Linus Torvalds
2008-01-16 20:36                       ` Junio C Hamano
2008-01-16 20:46                         ` Brandon Casey
2008-01-16 21:57                           ` Junio C Hamano
2008-01-16 22:46                             ` Brandon Casey
2008-01-16 22:55                               ` Junio C Hamano
2008-01-16 23:08                                 ` Brandon Casey
2008-01-16 23:16                                   ` Brandon Casey
2008-01-16 23:19                           ` Junio C Hamano
2008-01-16 23:28                             ` Brandon Casey
2008-01-16  7:53               ` git-commit fatal: Out of memory? mmap failed: Bad file descriptor Johannes Sixt
2008-01-15 12:21   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vejchr3pf.fsf_-_@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=casey@nrlssc.navy.mil \
    --cc=drafnel@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=krh@redhat.com \
    --cc=raa.lkml@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).