zsh-workers
 help / color / mirror / code / Atom feed
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Cedric Ware <cedric.ware__bml@normalesup.org>
Cc: dana <dana@dana.is>, <zsh-workers@zsh.org>
Subject: Re: [PATCH] Enable sub-second timeout in zsystem flock
Date: Sun, 15 Mar 2020 01:04:29 +0000	[thread overview]
Message-ID: <20200315010429.0155ba3d@tarpaulin.shahaf.local2> (raw)
In-Reply-To: <20200314210454.hp562smyqv3ew255@phare.normalesup.org>

Cedric Ware wrote on Sat, 14 Mar 2020 22:04 +0100:
> dana (Thursday 2020-03-12):
> > 2. This particular test doesn't seem reliable on my machine. Within the test
> >    harness, it normally takes about 0.078 seconds. Probably the fork over-head
> >    (which is pretty high on macOS) is greater than the amount of time you're
> >    giving it wait? If i change `zselect -t 1` to `zselect -t 10` it seems to
> >    work better... but it still feels very brittle. Very much dependent on the
> >    hardware, the OS, and the current resource utilisation  
> 
> I see.  Here's a new version of the patch.  As long as the tests are
> run sequentially and not in parallel, there shouldn't be any race
> condition left.  Instead of just waiting 10 ms and hoping that the
> sub-shell has had time to start in the background, I'm now actually
> testing the presence of a file that it creates.
> 
> It might still fail if the background sub-shell completes, including
> the several-tenths-of-a-second wait, before the next part of the test
> is run.  Do you think it's still too likely?

> +++ zsh-5.8/Test/V14system.ztst	2020-03-14 21:59:02.351858164 +0100
> @@ -0,0 +1,131 @@
> +# Test zsh/system module
> +  (
> +    # Lock file for 1 second in the background.
> +    (zsystem flock $tst_dir/file \
> +     && touch $tst_dir/locked \
> +     && zselect -t 100
> +     rm -f $tst_dir/locked) &
> +    # Wait until sub-shell above has started.
> +    while ! [[ -f $tst_dir/locked ]]; do
> +      zselect -t 1
> +    done

If «zsystem flock» returns non-zero, this loop will never terminate.

Tests should be written to always terminate, if possible; and if not,
they should warn about that on $ZTST_fd.  (The output of «make check»
has several examples of the latter.)

There are additional instances of this later in the file.

> +    # Attempt to lock file with 0.5 second timeout: must fail.
> +    zsystem flock -t 0.5 $tst_dir/file
> +  )
> +2:zsystem flock unsuccessful wait test
> +
> +  (
> +    # Wait until sub-shell of the previous test has finished.
> +    while [[ -f $tst_dir/locked ]]; do
> +      zselect -t 10
> +    done

Wouldn't it be easier to use a different file in this test than in the
previous test?  Tests should be independent of each other if possible.

> +    # Lock file for 0.5 second in the background.
> +    (zsystem flock $tst_dir/file \
> +      && touch $tst_dir/locked \
> +      && zselect -t 50
> +      rm -f $tst_dir/locked) &
> +    # Wait until sub-shell above has started.
> +    while ! [[ -f $tst_dir/locked ]]; do
> +      zselect -t 1
> +    done
> +    typeset -F SECONDS
> +    start=$SECONDS
> +    # Attempt to lock file without a timeout:
> +    # must succeed after sub-shell above releases it (0.5 second).
> +    if zsystem flock $tst_dir/file; then
> +      elapsed=$[ $SECONDS - $start ]
> +      if [[ $elapsed -ge 0.3 && $elapsed -le 0.7 ]]; then
> +        echo "elapsed time seems OK" 1>&2
> +      else
> +        echo "elapsed time $elapsed should be ~ 0.5 second" 1>&2
> +      fi
> +    fi
> +  )
> +0:zsystem flock successful wait test, no timeout
> +?elapsed time seems OK

How about adding some "F:" lines (to this and subsequent tests)
explaining that failure doesn't necessarily indicate a problem in zsh,
but could also be caused by process scheduling issues?

Cheers,

Daniel

  parent reply	other threads:[~2020-03-15  1:05 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-29 20:35 Cedric Ware
2019-07-29 22:25 ` Bart Schaefer
2020-01-04 18:47   ` Cedric Ware
2020-01-05 18:42     ` dana
2020-01-05 21:49       ` dana
2020-01-06 17:30       ` Cedric Ware
2020-01-06 17:36         ` Peter Stephenson
2020-01-07  3:48         ` dana
2020-01-11 15:41           ` Cedric Ware
2020-01-11 19:36             ` dana
2020-01-12  4:25               ` dana
2020-03-08 18:39                 ` Cedric Ware
2020-03-12 18:46                   ` dana
2020-03-12 19:13                     ` dana
2020-03-14 21:04                     ` Cedric Ware
2020-03-15  0:50                       ` Daniel Shahaf
2020-03-15  1:04                         ` dana
2020-03-15 16:03                         ` Cedric Ware
2020-03-15 16:54                           ` Daniel Shahaf
2020-03-15 17:35                             ` Peter Stephenson
2020-03-15 18:36                             ` Cedric Ware
2020-03-15 19:13                               ` Daniel Shahaf
2020-04-13 21:34                             ` Cedric Ware
2020-04-14 11:47                               ` Daniel Shahaf
2020-04-14 20:21                                 ` Cedric Ware
2020-04-15  1:15                                   ` Daniel Shahaf
2020-04-15  2:05                                     ` dana
2020-04-16  4:24                                       ` Daniel Shahaf
2020-04-18 16:32                                         ` Cedric Ware
2020-04-20 17:28                                           ` dana
2020-04-20 22:17                                             ` Cedric Ware
2020-03-15  1:04                       ` Daniel Shahaf [this message]
2020-03-13 14:26                   ` dana

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=20200315010429.0155ba3d@tarpaulin.shahaf.local2 \
    --to=d.s@daniel.shahaf.name \
    --cc=cedric.ware__bml@normalesup.org \
    --cc=dana@dana.is \
    --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).