From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id d537cbd7 for ; Tue, 7 Jan 2020 03:49:17 +0000 (UTC) Received: (qmail 29992 invoked by alias); 7 Jan 2020 03:49: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: 45260 Received: (qmail 23545 invoked by uid 1010); 7 Jan 2020 03:49:09 -0000 X-Qmail-Scanner-Diagnostics: from mail-yb1-f194.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.1/25684. spamassassin: 3.4.2. Clear:RC:0(209.85.219.194):SA:0(-1.9/5.0):. Processed in 2.722745 secs); 07 Jan 2020 03:49:09 -0000 X-Envelope-From: dana@dana.is X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.219.194 as permitted sender) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FsfDUoHMteuH5UEzp1lo8DW9haYmhtx1rMlDlgJvk6E=; b=OZbpNxI4KvvDHmWgvP1keekHHLD+Qow6m83oOeEmWq6aRy3+0/rlwNgvxNQyJYAZyZ sW3yAR9XRa8rdJ0+kGCr/QDETspCoYVRvAZICco7Wo2YPs9des/FehsjPnI9j/aSSVck ounjLo2bSWrgJDxpxG6Q/rP5xJvmISMrMCdm5VobNaMuJMOvcCQae2dye80SH48eQMHL w8YutUdfVe+sHrY2dE1aIaqQD5CDdLX5mo2bjQ8b/CrpWVAfgUBxqA8fRJeOt+Le7eR3 8W8V+H8g6/x8+1wf2UDYIbJUPPvksRAgiYlzaYk+6kfrwEQiKPvJ/oNKxWDcRlupst1Y eriA== X-Gm-Message-State: APjAAAUJGiC4/yECBR570tE10E9gFBXmC6Oh4d6p/OAf/u1LV9exkLTc 7ZELyNTknCElIWA/2FFC0YOyEw== X-Google-Smtp-Source: APXvYqxvcHDaucZ63YR54Xf88aeeJHxWlpP5CSLhMHqlZwN2PBcOYhUlUDsJDbSK62rAKzgvR82gZg== X-Received: by 2002:a25:3d3:: with SMTP id 202mr70425188ybd.17.1578368912265; Mon, 06 Jan 2020 19:48:32 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: [PATCH] Enable sub-second timeout in zsystem flock From: dana In-Reply-To: <20200106173030.eb2pg4rhhgysh35r@phare.normalesup.org> Date: Mon, 6 Jan 2020 21:48:30 -0600 Cc: "zsh-workers@zsh.org" Content-Transfer-Encoding: 7bit Message-Id: References: <20190729203521.upp5ku3bsr3hsnxq@phare.normalesup.org> <20200104184734.ienw42rwq2xu6aap@phare.normalesup.org> <43775C64-0254-45AB-81AB-B04AE80C4416@dana.is> <20200106173030.eb2pg4rhhgysh35r@phare.normalesup.org> To: Cedric Ware X-Mailer: Apple Mail (2.3445.104.11) On 6 Jan 2020, at 11:30, Cedric Ware wrote: > Not quite pointless: in the last iteration of the retry loop, if the > timeout is closer to the current time than the retry interval, zsleep() > only waits until the timeout, then there's a last locking attempt, and > only then the function fails. Oh, i missed that, sorry. That doesn't seem so bad. On 6 Jan 2020, at 11:30, Cedric Ware wrote: > Also, I thought I'd reuse the same mnumber variable to parse > the arguments of both -t and -i, but I can change that if it breaks the > coding style. It's fine afaik On 6 Jan 2020, at 11:30, Cedric Ware wrote: > Now that I've thought about it again, I added a similar check for the > timeout value even though it's a zlong, and I documented that the > interval is silently capped at LONG_MAX microseconds. Do you think > it should be reported as an error instead? Like i said, it doesn't seem to do much error-checking anywhere else, so i guess it's consistent... but if it were me i'd probably make any out-of-range value return an error, yeah. On 6 Jan 2020, at 11:30, Cedric Ware wrote: > Maybe. I believe CLOCK_MONOTONIC stops when the system is suspended; > Linux has CLOCK_BOOTIME that adds the suspend time, but it's not > portable. I don't know what would surprise users more between having > SECONDS run backwards (which it could now), and not including suspend > time (if it was changed to CLOCK_MONOTONIC). Since it's mainly used for timing things i think that'd be fine, but maybe there's something i'm not considering. On 6 Jan 2020, at 11:30, Cedric Ware wrote: > Thanks for the pointer. Yes, that could be done, though I don't have > the time right now. What I actually had in mind was a test suite I > could run to check that I didn't break anything elsewhere. Which is > "make test", I should have thought of it. The current tests are still > successful with the patch. I'm slightly busy again too but i could try to write a script for it later. It'd be going into 5.9 anyway dana