kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Jeff King	9658846ce3	write_or_die: handle EPIPE in async threads 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Jeff King	9540ce5030	refs: write packed_refs file using stdio 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 <peff@peff.net> Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>	11 years ago
Jeff King	756e676ca0	write_or_die: raise SIGPIPE when we get EPIPE 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Johannes Sixt	84adb64154	maybe_flush_or_die: move a too-loose Windows specific error 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 <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Thomas Rast	d824cbba02	Convert existing die(..., strerror(errno)) to die_errno() 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 <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Junio C Hamano	559e840b74	Move read_in_full() and write_in_full() to wrapper.c 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 <gitster@pobox.com>	17 years ago
Johannes Sixt	b2f5e2684d	Windows: Work around an oddity when a pipe with no reader is written to. 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 <johannes.sixt@telecom.at>	17 years ago
Linus Torvalds	4c81b03e30	Make pack creation always fsync() the result 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 <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Heikki Orsila	0104ca09e3	Make read_in_full() and write_in_full() consistent with xread() and xwrite() 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 <gitster@pobox.com>	17 years ago
Theodore Ts'o	06f59e9f5d	Don't fflush(stdout) when it's not helpful 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" <tytso@mit.edu> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Junio C Hamano	d848804a89	write_in_full: size_t is unsigned. 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 <junkio@cox.net>	18 years ago
Shawn O. Pearce	e6e2bd6201	Remove read_or_die in favor of better error messages. 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 <torvalds@osdl.org>: > 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 <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Linus Torvalds	4494c656e2	Fix up totally buggered read_or_die() 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 <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Linus Torvalds	d34cf19b89	Clean up write_in_full() users 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 <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Eric Wong	3b97fee23d	Avoid errors and warnings when attempting to do I/O on zero bytes 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 <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Linus Torvalds	f6aa66cb95	write_in_full: really write in full or return error on disk full. Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Andy Whitcroft	93822c2239	short i/o: fix calls to write to use xwrite or write_in_full 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 <apw@shadowen.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Andy Whitcroft	93d26e4cb9	short i/o: fix calls to read to use xread or read_in_full 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 <apw@shadowen.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Andy Whitcroft	e08140568a	short i/o: clean up the naming for the write_{in,or}_xxx family 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 <apw@shadowen.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Andy Whitcroft	825cee7b28	send pack check for failure to send revisions list 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 <apw@shadowen.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Shawn O. Pearce	75025ccdb7	Create read_or_die utility routine. 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 <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Christian Couder	6ce4e61f1b	Trace into a file or an open fd and refactor tracing code. 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 <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Christian Couder	7cf67205ca	Trace into open fd and refactor tracing code. 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 <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Rene Scharfe	7230e6d042	Add write_or_die(), a helper function 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 <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago

24 Commits (7431596ab1f05a13adb93b44108f27cfd6578a31)