git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH 0/3] Support stdio access to lockfiles

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Oct 1, 2014, 11:14 UTC
Message-ID
<1412162089-3233-1-git-send-email-mhagger@alum.mit.edu>

This series applies on top of the series "Lockfile correctness and refactoring" (Junio's branch mh/lockfile).

There are already two callers that write to lockfiles using stdio. But they currently need intimate knowledge of the lockfile implementation to work correctly; for example, they have to call fclose() themselves and set lk->fd to -1 to prevent the file from being closed again. This is awkward and error-prone.

So provide official API support for stdio-based access to lockfiles. Add a new function fdopen_lock_file(), which returns a (FILE *) associated with an open lockfile, and teach close_lock_file() (and therefore also commit_lock_file(), rollback_lock_file(), etc.) to use fclose() instead of close() on lockfiles for which fdopen_lock_file() has been called.

...except in the signal handler, where calling fclose() is not permitted. In the signal handler call close() on any still-open lockfiles regardless of whether they have been fdopen()ed. Since the very next step is to delete the file, this should be OK.

The second and third patches rewrite the two callers who currently fdopen() lockfiles to use the new function. I didn't look around for other lockfile users that might be simplified and/or sped up by converting them to use stdio; probably there are some.

This improvement was initially discussed when the second fdopen() callsite was added [1] and also when discussing inconsistencies between the documentation and real life in the context of the mh/lockfile patch series [2].

Michael

[1] http://thread.gmane.org/gmane.comp.version-control.git/256729/focus=256734 [2] http://thread.gmane.org/gmane.comp.version-control.git/257504/focus=257553

Michael Haggerty (3):
  fdopen_lock_file(): access a lockfile using stdio
  dump_marks(): reimplement using fdopen_lock_file()
  commit_packed_refs(): reimplement using fdopen_lock_file()
 Documentation/technical/api-lockfile.txt | 34 +++++++++++++++--------
 fast-import.c                            | 21 ++-------------
 lockfile.c                               | 46 ++++++++++++++++++++++++++++----
 lockfile.h                               |  4 +++
 refs.c                                   |  5 +---
 5 files changed, 71 insertions(+), 39 deletions(-)
-- 
2.1.0
Next: Michael Haggerty
Message 1 of 9 in “Support stdio access to lockfiles”
  1. 0/3 Support stdio access to lockfilesMichael Haggerty, Oct 1, 2014
  2. 1/3 fdopen_lock_file(): access a lockfile using stdioMichael Haggerty, Oct 1, 2014
  3. Jeff KingOct 1, 2014
  4. Junio C HamanoOct 1, 2014
  5. Torsten BögershausenOct 2, 2014
  6. Michael HaggertyOct 12, 2014
  7. 2/3 dump_marks(): reimplement using fdopen_lock_file()Michael Haggerty, Oct 1, 2014
  8. 3/3 commit_packed_refs(): reimplement using fdopen_lock_file()Michael Haggerty, Oct 1, 2014
  9. Jeff KingOct 1, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.