From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,RDNS_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 Received: (qmail 19591 invoked from network); 15 Mar 2020 01:05:15 -0000 Received-SPF: pass (primenet.com.au: domain of zsh.org designates 203.24.36.2 as permitted sender) receiver=inbox.vuxu.org; client-ip=203.24.36.2 envelope-from= Received: from unknown (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTP; 15 Mar 2020 01:05:15 -0000 Received: (qmail 22823 invoked by alias); 15 Mar 2020 01:05:09 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 45558 Received: (qmail 13409 invoked by uid 1010); 15 Mar 2020 01:05:09 -0000 X-Qmail-Scanner-Diagnostics: from out2-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.2/25744. spamassassin: 3.4.2. Clear:RC:0(66.111.4.26):SA:0(-2.6/5.0):. Processed in 0.803879 secs); 15 Mar 2020 01:05:09 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudeftddgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkjghfofggtgfgsehtqh dttdertdejnecuhfhrohhmpeffrghnihgvlhcuufhhrghhrghfuceougdrshesuggrnhhi vghlrdhshhgrhhgrfhdrnhgrmhgvqeenucfkphepuddtledrieegrddvvddrudeikeenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegurdhssegu rghnihgvlhdrshhhrghhrghfrdhnrghmvg X-ME-Proxy: Date: Sun, 15 Mar 2020 01:04:29 +0000 From: Daniel Shahaf To: Cedric Ware Cc: dana , Subject: Re: [PATCH] Enable sub-second timeout in zsystem flock Message-ID: <20200315010429.0155ba3d@tarpaulin.shahaf.local2> In-Reply-To: <20200314210454.hp562smyqv3ew255@phare.normalesup.org> References: <20200104184734.ienw42rwq2xu6aap@phare.normalesup.org> <43775C64-0254-45AB-81AB-B04AE80C4416@dana.is> <20200106173030.eb2pg4rhhgysh35r@phare.normalesup.org> <20200111154143.fjtwgfnztqfmkyda@phare.normalesup.org> <20200308183907.mxnhqrr2uflwooax@phare.normalesup.org> <20200314210454.hp562smyqv3ew255@phare.normalesup.org> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 ov= er-head > > (which is pretty high on macOS) is greater than the amount of time y= ou're > > giving it wait? If i change `zselect -t 1` to `zselect -t 10` it see= ms to > > work better... but it still feels very brittle. Very much dependent = on the > > hardware, the OS, and the current resource utilisation =20 >=20 > 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. >=20 > 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 =C2=ABzsystem flock=C2=BB returns non-zero, this loop will never termina= te. Tests should be written to always terminate, if possible; and if not, they should warn about that on $ZTST_fd. (The output of =C2=ABmake check= =C2=BB 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=3D$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=3D$[ $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