git/lockfile.c, branch v2.5.2

Merge branch 'js/sleep-without-select'

2015-06-24T19:21:47Z

Portability fix. * js/sleep-without-select: lockfile: wait using sleep_millisec() instead of select() lockfile: convert retry timeout computations to millisecond help.c: wrap wait-only poll() invocation in sleep_millisec() lockfile: replace random() by rand()

lockfile: wait using sleep_millisec() instead of select()

2015-06-05T22:00:32Z

Use the new function sleep_millisec() to delay execution for a short time. This avoids the invocation of select() with just a timeout, but no file descriptors. Such a use of select() is quit with EINVAL on Windows, leading to no delay at all. Signed-off-by: Johannes Sixt Reviewed-by: Michael Haggerty Signed-off-by: Junio C Hamano

lockfile: convert retry timeout computations to millisecond

2015-06-05T22:00:32Z

When the goal is to wait for some random amount of time up to one second, it is not necessary to compute with microsecond precision. This is a preparation to re-use sleep_millisec(). Signed-off-by: Johannes Sixt Reviewed-by: Michael Haggerty Signed-off-by: Junio C Hamano

lockfile: replace random() by rand()

2015-06-05T22:00:31Z

On Windows, we do not have functions srandom() and random(). Use srand() and rand(). These functions produce random numbers of lesser quality, but for the purpose (a retry time-out) they are still good enough. Signed-off-by: Johannes Sixt Reviewed-by: Michael Haggerty Signed-off-by: Junio C Hamano

Merge branch 'jc/ignore-epipe-in-filter'

2015-05-22T19:41:57Z

Filter scripts were run with SIGPIPE disabled on the Git side, expecting that they may not read what Git feeds them to filter. We however treated a filter that does not read its input fully before exiting as an error. This changes semantics, but arguably in a good way. If a filter can produce its output without consuming its input using whatever magic, we now let it do so, instead of diagnosing it as a programming error. * jc/ignore-epipe-in-filter: filter_buffer_or_fd(): ignore EPIPE copy.c: make copy_fd() report its status silently

copy.c: make copy_fd() report its status silently

2015-05-19T21:48:54Z

When copy_fd() function encounters errors, it emits error messages itself, which makes it impossible for callers to take responsibility for reporting errors, especially when they want to ignore certain errors. Move the error reporting to its callers in preparation. - copy_file() and copy_file_with_time() by indirection get their own calls to error(). - hold_lock_file_for_append(), when told to die on error, used to exit(128) relying on the error message from copy_fd(), but now it does its own die() instead. Note that the callers that do not pass LOCK_DIE_ON_ERROR need to be adjusted for this change, but fortunately there is none ;-) - filter_buffer_or_fd() has its own error() already, in addition to the message from copy_fd(), so this will change the output but arguably in a better way. Signed-off-by: Junio C Hamano

lockfile: allow file locking to be retried with a timeout

2015-05-14T21:51:08Z

Currently, there is only one attempt to lock a file. If it fails, the whole operation fails. But it might sometimes be advantageous to try acquiring a file lock a few times before giving up. So add a new function, hold_lock_file_for_update_timeout(), that allows a timeout to be specified. Make hold_lock_file_for_update() a thin wrapper around the new function. If timeout_ms is positive, then retry for at least that many milliseconds to acquire the lock. On each failed attempt, use select() to wait for a backoff time that increases quadratically (capped at 1 second) and has a random component to prevent two processes from getting synchronized. If timeout_ms is negative, retry indefinitely. In a moment we will switch to using the new function when locking packed-refs. Signed-off-by: Michael Haggerty Signed-off-by: Junio C Hamano

lockfile.c: store absolute path

2014-11-03T19:00:28Z

Locked paths can be saved in a linked list so that if something wrong happens, *.lock are removed. For relative paths, this works fine if we keep cwd the same, which is true 99% of time except: - update-index and read-tree hold the lock on $GIT_DIR/index really early, then later on may call setup_work_tree() to move cwd. - Suppose a lock is being held (e.g. by "git add") then somewhere down the line, somebody calls real_path (e.g. "link_alt_odb_entry"), which temporarily moves cwd away and back. During that time when cwd is moved (either permanently or temporarily) and we decide to die(), attempts to remove relative *.lock will fail, and the next operation will complain that some files are still locked. Avoid this case by turning relative paths to absolute before storing the path in "filename" field. Reported-by: Yue Lin Ho Helped-by: Ramsay Jones Helped-by: Johannes Sixt Signed-off-by: Nguyễn Thái Ngọc Duy Adapted-by: Michael Haggerty Signed-off-by: Michael Haggerty Signed-off-by: Junio C Hamano

lockfile: remove unable_to_lock_error

2014-10-15T17:47:27Z

The former caller uses unable_to_lock_message now. Signed-off-by: Jonathan Nieder Reviewed-by: Ronnie Sahlberg Signed-off-by: Junio C Hamano

Merge branch 'mh/lockfile-stdio'

2014-10-14T17:49:52Z

* mh/lockfile-stdio: commit_packed_refs(): reimplement using fdopen_lock_file() dump_marks(): reimplement using fdopen_lock_file() fdopen_lock_file(): access a lockfile using stdio