1. 11 Apr, 2018 1 commit
  2. 17 Oct, 2016 1 commit
  3. 05 Aug, 2016 1 commit
    • Jeff King's avatar
      write_or_die: drop write_or_whine_pipe() · ca5c701c
      Jeff King authored
      This function has no callers, and is not likely to gain any
      because it's confusing to use.
      
      It unconditionally complains to stderr, but _doesn't_ die.
      Yet any caller which wants a "gentle" write would generally
      want to suppress the error message, because presumably
      they're going to write a better one, and/or try the
      operation again.
      
      And the check_pipe() call leads to confusing behaviors. It
      means we die for EPIPE, but not for other errors, which is
      confusing and pointless.
      
      On top of all that, it has unusual error return semantics,
      which makes it easy for callers to get it wrong.
      
      Let's drop the function, and if somebody ever needs to
      resurrect something like it, they can fix these warts.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ca5c701c
  4. 10 Jun, 2016 1 commit
  5. 25 Feb, 2016 1 commit
    • Jeff King's avatar
      write_or_die: handle EPIPE in async threads · 9658846c
      Jeff King authored
      When write_or_die() sees EPIPE, it treats it specially by
      converting it into a SIGPIPE death. We obviously cannot
      ignore it, as the write has failed and the caller expects us
      to die. But likewise, we cannot just call die(), because
      printing any message at all would be a nuisance during
      normal operations.
      
      However, this is a problem if write_or_die() is called from
      a thread. Our raised signal ends up killing the whole
      process, when logically we just need to kill the thread
      (after all, if we are ignoring SIGPIPE, there is good reason
      to think that the main thread is expecting to handle it).
      
      Inside an async thread, the die() code already does the
      right thing, because we use our custom die_async() routine,
      which calls pthread_join(). So ideally we would piggy-back
      on that, and simply call:
      
        die_quietly_with_code(141);
      
      or similar. But refactoring the die code to do this is
      surprisingly non-trivial. The die_routines themselves handle
      both printing and the decision of the exit code. Every one
      of them would have to be modified to take new parameters for
      the code, and to tell us to be quiet.
      
      Instead, we can just teach write_or_die() to check for the
      async case and handle it specially. We do have to build an
      interface to abstract the async exit, but it's simple and
      self-contained. If we had many call-sites that wanted to do
      this die_quietly_with_code(), this approach wouldn't scale
      as well, but we don't. This is the only place where do this
      weird exit trick.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      9658846c
  6. 10 Sep, 2014 1 commit
    • Jeff King's avatar
      refs: write packed_refs file using stdio · 9540ce50
      Jeff King authored
      We write each line of a new packed-refs file individually
      using a write() syscall (and sometimes 2, if the ref is
      peeled). Since each line is only about 50-100 bytes long,
      this creates a lot of system call overhead.
      
      We can instead open a stdio handle around our descriptor and
      use fprintf to write to it. The extra buffering is not a
      problem for us, because nobody will read our new packed-refs
      file until we call commit_lock_file (by which point we have
      flushed everything).
      
      On a pathological repository with 8.5 million refs, this
      dropped the time to run `git pack-refs` from 20s to 6s.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Reviewed-by: default avatarMichael Haggerty <mhagger@alum.mit.edu>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      9540ce50
  7. 20 Feb, 2013 1 commit
    • Jeff King's avatar
      write_or_die: raise SIGPIPE when we get EPIPE · 756e676c
      Jeff King authored
      The write_or_die function will always die on an error,
      including EPIPE. However, it currently treats EPIPE
      specially by suppressing any error message, and by exiting
      with exit code 0.
      
      Suppressing the error message makes some sense; a pipe death
      may just be a sign that the other side is not interested in
      what we have to say. However, exiting with a successful
      error code is not a good idea, as write_or_die is frequently
      used in cases where we want to be careful about having
      written all of the output, and we may need to signal to our
      caller that we have done so (e.g., you would not want a push
      whose other end has hung up to report success).
      
      This distinction doesn't typically matter in git, because we
      do not ignore SIGPIPE in the first place. Which means that
      we will not get EPIPE, but instead will just die when we get
      a SIGPIPE. But it's possible for a default handler to be set
      by a parent process, or for us to add a callsite inside one
      of our few SIGPIPE-ignoring blocks of code.
      
      This patch converts write_or_die to actually raise SIGPIPE
      when we see EPIPE, rather than exiting with zero. This
      brings the behavior in line with the "normal" case that we
      die from SIGPIPE (and any callers who want to check why we
      died will see the same thing). We also give the same
      treatment to other related functions, including
      write_or_whine_pipe and maybe_flush_or_die.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      756e676c
  8. 17 Oct, 2012 1 commit
  9. 27 Jun, 2009 1 commit
  10. 21 Jul, 2008 1 commit
  11. 26 Jun, 2008 1 commit
  12. 31 May, 2008 1 commit
  13. 30 Apr, 2008 1 commit
  14. 01 Jul, 2007 1 commit
    • Theodore Ts'o's avatar
      Don't fflush(stdout) when it's not helpful · 06f59e9f
      Theodore Ts'o authored
      This patch arose from a discussion started by Jim Meyering's patch
      whose intention was to provide better diagnostics for failed writes.
      Linus proposed a better way to do things, which also had the added
      benefit that adding a fflush() to git-log-* operations and incremental
      git-blame operations could improve interactive respose time feel, at
      the cost of making things a bit slower when we aren't piping the
      output to a downstream program.
      
      This patch skips the fflush() calls when stdout is a regular file, or
      if the environment variable GIT_FLUSH is set to "0".  This latter can
      speed up a command such as:
      
      GIT_FLUSH=0 strace -c -f -e write time git-rev-list HEAD | wc -l
      
      a tiny amount.
      Signed-off-by: Theodore Ts'o's avatar"Theodore Ts'o" <tytso@mit.edu>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      06f59e9f
  15. 27 Jan, 2007 1 commit
  16. 14 Jan, 2007 1 commit
  17. 12 Jan, 2007 2 commits
    • Linus Torvalds's avatar
      Fix up totally buggered read_or_die() · 4494c656
      Linus Torvalds authored
      The "read_or_die()" function would silently NOT die for a partial read,
      and since it was of type "void" it obviously couldn't even return the
      partial number of bytes read.
      
      IOW, it was totally broken. This hopefully fixes it up.
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      4494c656
    • Linus Torvalds's avatar
      Clean up write_in_full() users · d34cf19b
      Linus Torvalds authored
      With the new-and-improved write_in_full() semantics, where a partial write
      simply always returns a real error (and always sets 'errno' when that
      happens, including for the disk full case), a lot of the callers of
      write_in_full() were just unnecessarily complex.
      
      In particular, there's no reason to ever check for a zero length or
      return: if the length was zero, we'll return zero, otherwise, if a disk
      full resulted in the actual write() system call returning zero the
      write_in_full() logic would have correctly turned that into a negative
      return value, with 'errno' set to ENOSPC.
      
      I really wish every "write_in_full()" user would just check against "<0"
      now, but this fixes the nasty and stupid ones.
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      d34cf19b
  18. 11 Jan, 2007 2 commits
  19. 08 Jan, 2007 3 commits
    • Andy Whitcroft's avatar
      short i/o: fix calls to write to use xwrite or write_in_full · 93822c22
      Andy Whitcroft authored
      We have a number of badly checked write() calls.  Often we are
      expecting write() to write exactly the size we requested or fail,
      this fails to handle interrupts or short writes.  Switch to using
      the new write_in_full().  Otherwise we at a minimum need to check
      for EINTR and EAGAIN, where this is appropriate use xwrite().
      
      Note, the changes to config handling are much larger and handled
      in the next patch in the sequence.
      Signed-off-by: default avatarAndy Whitcroft <apw@shadowen.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      93822c22
    • Andy Whitcroft's avatar
      short i/o: fix calls to read to use xread or read_in_full · 93d26e4c
      Andy Whitcroft authored
      We have a number of badly checked read() calls.  Often we are
      expecting read() to read exactly the size we requested or fail, this
      fails to handle interrupts or short reads.  Add a read_in_full()
      providing those semantics.  Otherwise we at a minimum need to check
      for EINTR and EAGAIN, where this is appropriate use xread().
      Signed-off-by: default avatarAndy Whitcroft <apw@shadowen.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      93d26e4c
    • Andy Whitcroft's avatar
      short i/o: clean up the naming for the write_{in,or}_xxx family · e0814056
      Andy Whitcroft authored
      We recently introduced a write_in_full() which would either write
      the specified object or emit an error message and fail.  In order
      to fix the read side we now want to introduce a read_in_full()
      but without an error emit.  This patch cleans up the naming
      of this family of calls:
      
      1) convert the existing write_or_whine() to write_or_whine_pipe()
         to better indicate its pipe specific nature,
      2) convert the existing write_in_full() calls to write_or_whine()
         to better indicate its nature,
      3) introduce a write_in_full() providing a write or fail semantic,
         and
      4) convert write_or_whine() and write_or_whine_pipe() to use
         write_in_full().
      Signed-off-by: default avatarAndy Whitcroft <apw@shadowen.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      e0814056
  20. 03 Jan, 2007 1 commit
  21. 29 Dec, 2006 1 commit
  22. 02 Sep, 2006 1 commit
    • Christian Couder's avatar
      Trace into a file or an open fd and refactor tracing code. · 6ce4e61f
      Christian Couder authored
      If GIT_TRACE is set to an absolute path (starting with a
      '/' character), we interpret this as a file path and we
      trace into it.
      
      Also if GIT_TRACE is set to an integer value greater than
      1 and lower than 10, we interpret this as an open fd value
      and we trace into it.
      
      Note that this behavior is not compatible with the
      previous one.
      
      We also trace whole messages using one write(2) call to
      make sure messages from processes do net get mixed up in
      the middle.
      
      This patch makes it possible to get trace information when
      running "make test".
      Signed-off-by: Christian Couder's avatarChristian Couder <chriscool@tuxfamily.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      6ce4e61f
  23. 31 Aug, 2006 1 commit
  24. 22 Aug, 2006 1 commit
    • Rene Scharfe's avatar
      Add write_or_die(), a helper function · 7230e6d0
      Rene Scharfe authored
      The little helper write_or_die() won't come back with bad news about
      full disks or broken pipes.  It either succeeds or terminates the
      program, making additional error handling unnecessary.
      
      This patch adds the new function and uses it to replace two similar
      ones (the one in tar-tree originally has been copied from cat-file
      btw.).  I chose to add the fd parameter which both lacked to make
      write_or_die() just as flexible as write() and thus suitable for
      lib-ification.
      
      There is a regression: error messages emitted by this function don't
      show the program name, while the replaced two functions did.  That's
      acceptable, I think; a lot of other functions do the same.
      Signed-off-by: default avatarRene Scharfe <rene.scharfe@lsrfire.ath.cx>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      7230e6d0