path: root/write_or_die.c
AgeCommit message (Collapse)Author
2018-04-11write_or_die.c: rename to use dashes in file nameStefan Beller
This is more consistent with the project style. The majority of Git's source files use dashes in preference to underscores in their file names. Signed-off-by: Stefan Beller <>
2016-10-17run-command: move check_pipe() from write_or_die to run_commandLars Schneider
Move check_pipe() to run_command and make it public. This is necessary to call the function from pkt-line in a subsequent patch. While at it, make async_exit() static to run_command.c as it is no longer used from outside. Signed-off-by: Lars Schneider <> Signed-off-by: Ramsay Jones <> Signed-off-by: Junio C Hamano <>
2016-08-05write_or_die: drop write_or_whine_pipe()Jeff King
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: Jeff King <> Signed-off-by: Junio C Hamano <>
2016-06-10write_or_die: remove the unused write_or_whine() functionRamsay Jones
Now the last caller of this function is gone, and new ones are unlikely to appear, because this function is doing very little that a regular if() does not besides obfuscating the error message (and if we ever did want something like it, we would probably prefer the function to come back with more "normal" return value semantics). Signed-off-by: Ramsay Jones <> Signed-off-by: Junio C Hamano <>
2016-02-25write_or_die: handle EPIPE in async threadsJeff King
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: Jeff King <> Signed-off-by: Junio C Hamano <>
2014-09-10refs: write packed_refs file using stdioJeff King
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: Jeff King <> Reviewed-by: Michael Haggerty <> Signed-off-by: Junio C Hamano <>
2013-02-20write_or_die: raise SIGPIPE when we get EPIPEJeff King
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: Jeff King <> Signed-off-by: Junio C Hamano <>
2012-10-17maybe_flush_or_die: move a too-loose Windows specific errorJohannes Sixt
check to compat Commit b2f5e268 (Windows: Work around an oddity when a pipe with no reader is written to) introduced a check for EINVAL after fflush() to fight spurious "Invalid argument" errors on Windows when a pipe was broken. But this check may hide real errors on systems that do not have the this odd behavior. Introduce an fflush wrapper in compat/mingw.* so that the treatment is only applied on Windows. Signed-off-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2009-06-27Convert existing die(..., strerror(errno)) to die_errno()Thomas Rast
Change calls to die(..., strerror(errno)) to use the new die_errno(). In the process, also make slight style adjustments: at least state _something_ about the function that failed (instead of just printing the pathname), and put paths in single quotes. Signed-off-by: Thomas Rast <> Signed-off-by: Junio C Hamano <>
2008-07-21Move read_in_full() and write_in_full() to wrapper.cJunio C Hamano
A few compat/* layer functions call these functions, but we would really want to keep them thin, without depending too much on the libgit proper. Signed-off-by: Junio C Hamano <>
2008-06-26Windows: Work around an oddity when a pipe with no reader is written to.Johannes Sixt
On Windows, write() is implemented using WriteFile(). After the reader closed its end of the pipe, the first WriteFile() returns ERROR_BROKEN_PIPE (which translates to EPIPE), subsequent WriteFile()s return ERROR_NO_DATA, which is translated to EINVAL. Signed-off-by: Johannes Sixt <>
2008-05-31Make pack creation always fsync() the resultLinus Torvalds
This means that we can depend on packs always being stable on disk, simplifying a lot of the object serialization worries. And unlike loose objects, serializing pack creation IO isn't going to be a performance killer. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2008-04-30Make read_in_full() and write_in_full() consistent with xread() and xwrite()Heikki Orsila
xread() and xwrite() return ssize_t values as their native POSIX counterparts read(2) and write(2). To be consistent, read_in_full() and write_in_full() should also return ssize_t values. Signed-off-by: Junio C Hamano <>
2007-07-01Don't fflush(stdout) when it's not helpfulTheodore Ts'o
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" <> Acked-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2007-01-27write_in_full: size_t is unsigned.Junio C Hamano
It received the return value from xwrite() in a size_t variable 'written' and expected comparison with 0 would catch an error from xwrite(). Signed-off-by: Junio C Hamano <>
2007-01-14Remove read_or_die in favor of better error messages.Shawn O. Pearce
Originally I introduced read_or_die for the purpose of reading the pack header and trailer, and I was too lazy to print proper error messages. Linus Torvalds <>: > For a read error, at the very least you have to say WHICH FILE > couldn't be read, because it's usually a matter of some file just > being too short, not some system-wide problem. and of course Linus is right. Make it so. Signed-off-by: Shawn O. Pearce <> Signed-off-by: Junio C Hamano <>
2007-01-12Fix up totally buggered read_or_die()Linus Torvalds
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: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2007-01-12Clean up write_in_full() usersLinus Torvalds
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: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2007-01-11Avoid errors and warnings when attempting to do I/O on zero bytesEric Wong
Unfortunately, while {read,write}_in_full do take into account zero-sized reads/writes; their die and whine variants do not. I have a repository where there are zero-sized files in the history that was triggering these things. Signed-off-by: Eric Wong <> Signed-off-by: Junio C Hamano <>
2007-01-11write_in_full: really write in full or return error on disk full.Linus Torvalds
Signed-off-by: Junio C Hamano <>
2007-01-08short i/o: fix calls to write to use xwrite or write_in_fullAndy Whitcroft
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: Andy Whitcroft <> Signed-off-by: Junio C Hamano <>
2007-01-08short i/o: fix calls to read to use xread or read_in_fullAndy Whitcroft
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: Andy Whitcroft <> Signed-off-by: Junio C Hamano <>
2007-01-08short i/o: clean up the naming for the write_{in,or}_xxx familyAndy Whitcroft
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: Andy Whitcroft <> Signed-off-by: Junio C Hamano <>
2007-01-07Merge branch 'sp/mmap'Junio C Hamano
* sp/mmap: (27 commits) Spell default packedgitlimit slightly differently Increase packedGit{Limit,WindowSize} on 64 bit systems. Update packedGit config option documentation. mmap: set FD_CLOEXEC for file descriptors we keep open for mmap() pack-objects: fix use of use_pack(). Fix random segfaults in pack-objects. Cleanup read_cache_from error handling. Replace mmap with xmmap, better handling MAP_FAILED. Release pack windows before reporting out of memory. Default core.packdGitWindowSize to 1 MiB if NO_MMAP. Test suite for sliding window mmap implementation. Create pack_report() as a debugging aid. Support unmapping windows on 'temporary' packfiles. Improve error message when packfile mmap fails. Ensure core.packedGitWindowSize cannot be less than 2 pages. Load core configuration in git-verify-pack. Fully activate the sliding window pack access. Unmap individual windows rather than entire files. Document why header parsing won't exceed a window. Loop over pack_windows when inflating/accessing data. ... Conflicts: cache.h pack-check.c
2007-01-03send pack check for failure to send revisions listAndy Whitcroft
When passing the revisions list to pack-objects we do not check for errors nor short writes. Introduce a new write_in_full which will handle short writes and report errors to the caller. Use this to short cut the send on failure, allowing us to wait for and report the child in case the failure is its fault. Signed-off-by: Andy Whitcroft <> Signed-off-by: Junio C Hamano <>
2006-12-29Create read_or_die utility routine.Shawn O. Pearce
Like write_or_die read_or_die reads the entire length requested or it kills the current process with a die call. Signed-off-by: Shawn O. Pearce <> Signed-off-by: Junio C Hamano <>
2006-08-31Trace into open fd and refactor tracing code.Christian Couder
Now 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. It's now possible to run the tests like this: GIT_TRACE=9 make test 9>/var/tmp/trace.log Signed-off-by: Christian Couder <> Signed-off-by: Junio C Hamano <>
2006-08-22Add write_or_die(), a helper functionRene Scharfe
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: Rene Scharfe <> Signed-off-by: Junio C Hamano <>