Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111654 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 45072 invoked from network); 20 Aug 2020 13:53:33 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 20 Aug 2020 13:53:33 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 0F4F618050A for ; Thu, 20 Aug 2020 05:55:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-mahalux.mvorisek.com (mail-mahalux.mvorisek.com [77.93.195.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 20 Aug 2020 05:55:11 -0700 (PDT) Received: from 4d16232ded31 (10.228.0.190) by mail-mahalux.mvorisek.com (10.228.0.4) with Microsoft SMTP Server (TLS); Thu, 20 Aug 2020 14:55:10 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_a0fb66bbf73972670185c6f9c438410e" Date: Thu, 20 Aug 2020 14:55:09 +0200 To: PHP internals In-Reply-To: References: <6cfb77d4d511b5c591e7d7b5cc80199955123b2cd4276a5bca2327e4b02942db@mahalux.com> <4a6d97c1-28e8-c6cb-e985-d32c5d056ec0@telia.com> Message-ID: <6580abc6e6d8d73f1722d3070ec5214c7d0ba13759b97c60eacf57cfbfae50ab@mahalux.com> X-Mailer: SAP NetWeaver 7.03 Subject: Re: [PHP-DEV] Allow sleep() to accept non-integer values From: vorismi3@fel.cvut.cz (=?UTF-8?Q?Michael_Vo=C5=99=C3=AD=C5=A1ek_-_=C4=8CVUT_FEL?=) --=_a0fb66bbf73972670185c6f9c438410e Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed > Again, I personally don't understand why this could bypass the RFC process, as multiple people have already, me included, voiced their disagreement with this change. This was proposed by Nikita Popov in his comment > Secondly this change introduces another inconsistency, why can sleep accept a float but not usleep? Nanosleep and microsleep functions are basically 1:1 of the underlaying implementation. The updated sleep() is however now never worse than the best sleep function available, thus we can use it also for time_nanosleep and usleep php function and accept float. I will implement it. > If there is indeed a need for being able to specify a sleep in milliseconds I'd prefer the introduction of a msleep function then this change. The issue I solve is sleep function that accepts seconds should accept floating point values as time is continous value. With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek On 20 Aug 2020 14:25, G. P. B. wrote: > Apologies for the double email, my client did something funcky. > > On Thu, 20 Aug 2020 at 14:22, G. P. B. wrote: > > On Thu, 20 Aug 2020 at 14:15, Michael Voříšek - ČVUT FEL wrote: Hi everyone, > > thank you for your comments, based on them, I fixed these: > > - usleep is now used as a fallback as well, if interrupted, remaining > time is measured using microtime, so return value is always available > > - for BC, if not interrupted, return value remains to be 0 (integer > zero) > > Now, the sleep() function should be really universal, cross platform and > I would say also the prefered way to sleep. > > The implementaion is here https://github.com/php/php-src/pull/5961/files > > Please comment on Github directly if you have any feedback left. > >> I thinkit's worth considering if this also should be fixed in 8.0 or even earlier ;-)So good to hear the RM view on this. > > Sara, are you ok to include this in PHP 8.0 and do you require a RFC for > it? > > With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, > > Michael Voříšek Again, I personally don't understand why this could bypass the RFC process, as multiple people have already, me included, voiced their disagreement with this change. Secondly this change introduces another inconsistency, why can sleep accept a float but not usleep? If there is indeed a need for being able to specify a sleep in milliseconds I'd prefer the introduction of a msleep function then this change. Best regards George P. Banyard --=_a0fb66bbf73972670185c6f9c438410e--