Re: [PATCH 1/2] lockfile: allow file locking to be retried with a timeout
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 11, 2015, 18:04 UTC
- Message-ID
- <xmqq38337zy1.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <1430491977-25817-2-git-send-email-mhagger@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
Show 26 quoted lines
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
>
> Notes (discussion):
> It would be easy to also add a hold_lock_file_for_append_timeout(),
> but I can't yet think of an application for it.
>
> lockfile.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
> lockfile.h | 16 +++++++++++--
> 2 files changed, 91 insertions(+), 4 deletions(-)
>
> diff --git a/lockfile.c b/lockfile.c
> index 9889277..30e65e9 100644
> --- a/lockfile.c
> +++ b/lockfile.c
> @@ -157,6 +157,80 @@ static int lock_file(struct lock_file *lk, const char *path, int flags)
> return lk->fd;
> }
>
> +static int sleep_microseconds(long us)
> +{
> + struct timeval tv;
> + tv.tv_sec = 0;
> + tv.tv_usec = us;
> + return select(0, NULL, NULL, NULL, &tv);
> +}This is familiar for an old timer like me. It seems help.c uses "poll(NULL, 0, timeout)" for "do nothing but wait" (and we have compat/poll to help those who lack poll() by using select()).
As we do not need microseconds resolution here, either would be fine ;-)