zsh-workers
 help / color / mirror / code / Atom feed
From: dana <dana@dana.is>
To: Cedric Ware <cedric.ware__bml@normalesup.org>
Cc: "zsh-workers@zsh.org" <zsh-workers@zsh.org>
Subject: Re: [PATCH] Enable sub-second timeout in zsystem flock
Date: Thu, 12 Mar 2020 13:46:15 -0500	[thread overview]
Message-ID: <DC334422-54BA-4127-B8FB-F412FFB32287@dana.is> (raw)
In-Reply-To: <20200308183907.mxnhqrr2uflwooax@phare.normalesup.org>

Sorry for the delay.

On 8 Mar 2020, at 13:39, Cedric Ware <cedric.ware__bml@normalesup.org> wrote:
> One thing about the tests: I've used the (...)& syntax to launch a
> sub-shell in the background for concurrency checks.  But does the test
> script wait for sub-processes to finish between tests?

It does not, no.

Some more comments:

> +  (
> +    : > $tst_dir/file
> +    zsystem flock -t 0.1 -i 0.000001 $tst_dir/file
> +  )

If this file is meant to be used by the other tests, it seems like it might
make more sense to create it in %prep. Like it'll be fine this way, but unless
there's a specific reason to do it like that...

> +  (
> +    typeset -F SECONDS
> +    start=$SECONDS
> +    (zsystem flock $tst_dir/file && zselect -t 50) &
> +    zselect -t 1
> +    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
> +    else
> +      false
> +    fi
> +  )

1. All of the `else false`es in these tests seem redundant. If the condition
   doesn't pass it'll return >0 automatically, and the test will fail if it
   doesn't get the right output anyway

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

dana


  reply	other threads:[~2020-03-12 18:47 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 [this message]
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
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=DC334422-54BA-4127-B8FB-F412FFB32287@dana.is \
    --to=dana@dana.is \
    --cc=cedric.ware__bml@normalesup.org \
    --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).