From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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.4 Received: (qmail 27224 invoked from network); 27 Jun 2020 17:02:12 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 27 Jun 2020 17:02:12 -0000 Received: (qmail 3737 invoked by alias); 27 Jun 2020 17:01:56 -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: Sender: zsh-workers@zsh.org X-Seq: 46147 Received: (qmail 25741 invoked by uid 1010); 27 Jun 2020 17:01:56 -0000 X-Qmail-Scanner-Diagnostics: from mail-ot1-f50.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25850. spamassassin: 3.4.4. Clear:RC:0(209.85.210.50):SA:0(-1.9/5.0):. Processed in 2.160125 secs); 27 Jun 2020 17:01:56 -0000 X-Envelope-From: schaefer@brasslantern.com 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.210.50 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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yOu4Y0s3z1n0xkzULsw8Ck6+hELaeDmuad04nR3L0wo=; b=Gr7W3PtO7w6in2wU20eC9IkQJtZPffOG97k/37TdLLVIX1Fu+QllqIHRfvjs+1RIR8 41QZZow6RErG8grmM/3FYPnNLWLdp3p1kre8WLpHiXkFsDuRaL00tb2UowuoLq30LFmN 5pRwPFBQ/Wcujw8O1rgZn8AuxRC2TCUa0TMmpCEqpwngVuLNuADLqdVE1aqKAhfz2Kqc yrhWxyOMGcNSwFtLpwN0qxNGJ+ifpNXTdC5JzsTvqGNRTFL6HZUw45zqpnDjuqSKoInv MZXo2Gtqj6xwav+XP8WW8AdEpKemRRCacDbMwrkC0Dw8ql+s7TxHadzZ7yWBCWLz33CT EYkA== X-Gm-Message-State: AOAM531m8HiAj0QOyztS1UhBlZwMdNSYSt1bXIYB5AxK5a9n02dwJexn cwI0W9BsJKrKKrfAYAAzzXCS0I8XnMshNJ8k9ekjww== X-Google-Smtp-Source: ABdhPJwMDDChf04GOeBaF6f2kuTnmu6pbkOf8xA3HFIqRTisNAg0EDHJ9/iEd5/PmDjNmughheGV3vkAys00JpP7umA= X-Received: by 2002:a9d:5d11:: with SMTP id b17mr7496230oti.260.1593277279650; Sat, 27 Jun 2020 10:01:19 -0700 (PDT) MIME-Version: 1.0 References: <20200626141644.7cb5e511@tarpaulin.shahaf.local2> <20200627014717.68986199@tarpaulin.shahaf.local2> <20200627071350.zqkdhzbk3mfej2tz@phare.normalesup.org> In-Reply-To: From: Bart Schaefer Date: Sat, 27 Jun 2020 10:01:08 -0700 Message-ID: Subject: Re: [BUG] zsystem:34: flock: invalid timeout value: '0' To: Roman Perepelitsa Cc: Cedric Ware , Daniel Shahaf , Sebastian Gniazdowski , Zsh hackers list Content-Type: multipart/alternative; boundary="00000000000048671e05a913c6cb" --00000000000048671e05a913c6cb Content-Type: text/plain; charset="UTF-8" On Sat, Jun 27, 2020 at 12:27 AM Roman Perepelitsa < roman.perepelitsa@gmail.com> wrote: > > Timeout strictly between 0 and 1 microsecond is not much different > from timeout between 1 and 2 microseconds. You can either round up or > down in both cases. Rounding up is the right thing to do for sleeps > and timeouts because it allows you to provide a guarantee. > I would be mildly surprised if this doesn't happen as part of the OS implementation of the operation. --00000000000048671e05a913c6cb--