zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.w.stephenson@ntlworld.com>
To: ondra@mistotebe.net
Cc: zsh workers <zsh-workers@zsh.org>
Subject: Re: History file lock contention
Date: Fri, 23 Jan 2015 12:13:09 +0000	[thread overview]
Message-ID: <CAECNH1T5WoD27SjiGmad9YjPq04RPa8iy0wc6nhHUyR2ftpdpw@mail.gmail.com> (raw)
In-Reply-To: <20150123114628.GB10898@mistotebe.net>

[-- Attachment #1: Type: text/plain, Size: 1986 bytes --]

On 23 January 2015 at 11:46, <ondra@mistotebe.net> wrote:
> when running zsh from a terminal multiplexer like tmux, it is possible
> (and not uncommon) to close several processes at the exact same moment.
> In that case, all of them try to sync their history and all but one fail
> to acquire the lock. So far so good.
>
> However, all of these call nanosleep({1,0}), and since we might be on a
> multicore system, they might just be scheduled at the same time again,
> only one of them will progress and the scenario repeats. What the user
> sees is the terminals not disappearing immediately, but one after the
> other, a second per process.
>
> A common solution to this problem is to randomize the back-off, for
> example in the interval (0, 1s). On a decent system without load, this
> would make it more responsive (all of them would be likely to finish
> within a second of the user's request if possible) while not causing
> any undue increase in the load on the machine.

Yes, this is sensible.  I think the current simplistic algorithm
is mostly there because we aren't making assumptions about the
availability of sleep with a resolution better than 1 second ---
and a random backoff of multiples of seconds isn't very useful.
However, it can be improved in various largely standard ways which
are already used in other parts of the shell, so this is fixable without
needing to rely on system specific features.

A better scheme would be to start with a small wait time, says 0.1 seconds,
with a random back off, with a maximum length of say the same time again,
and then double the base time each time we back off, but keeping the
same maximum time of 10 seconds since we first tried before reporting
a failure.  We can then tweak this as necessary.  Or maybe just
having a random backoff with doubling maximum and no fixed
base time is good enough for typical problems.

pws

P.S. if acronyms like EDCA and SIFS went through anyone else's mind,
too, my commiserations :-).

  reply	other threads:[~2015-01-23 12:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-23 11:46 ondra
2015-01-23 12:13 ` Peter Stephenson [this message]
2015-01-23 20:49   ` Peter Stephenson
2015-01-23 21:00     ` Peter Stephenson
2015-01-23 21:28       ` Peter Stephenson
2015-01-25 20:33         ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAECNH1T5WoD27SjiGmad9YjPq04RPa8iy0wc6nhHUyR2ftpdpw@mail.gmail.com \
    --to=p.w.stephenson@ntlworld.com \
    --cc=ondra@mistotebe.net \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).