Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
On Saturday, 9 March 2024 at 19:44, Jim Winstead wrote: > This may be a dumb question, but what's the process for determining whether > the next significant release of PHP will be a minor version or a major > version? If the adherence to semantic versioning is meant to be strict, it > doesn't make any sense to vote on what version something like belongs to, > because then you're saying that whether a BC break is significant enough to > merit an increase to the major version is up for vote. We don't follow semver and never have. There have been BC breaks in every single minor version of PHP since PHP 4. The general attitude is that minor BC breaks are OK in minor versions and must be clearly documented. I will also mention that most programming languages to not follow semver and instead have a set number of versions a deprecated feature exists before being removed, Python being the most famous example. There is no process on how or when a major version should occur and AFAIK it has always been a core developper choice when to push for a version to be a major. Me, and some other members of the Foundation, currently don't see the immediate benefit of having a major version soon. For me, what would cause the roll-over to PHP 9 is converting streams from resources to objects as this not only has a relatively large impact on userland (that we can talk about how to mitigate) but also impacts every single PHP extension that uses streams in some capacity. I also have another selfish reason for wanting to delay PHP 9 for at least another minor version as I still have a large language semantic RFC (in the vein of the container/offset one I just posed) I want to do, which I'm not sure I'll have ready in time before the feature freeze of PHP 8.4. Best regards, Gina P. Banyard
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
Hi On 3/8/24 09:12, Hans Henrik Bergan wrote: Does this work for you guys? As said before, not a fan of the voting choices, because of the implicit dependencies that you would need to carefully specify. adding a short *nix explanation of when sleep will return earlier than expected would be helpful Where should that be? in the "Introduction" section? or the "Proposal" section? (or elsewhere?) With the current structure of the RFC I believe it would fit best within the Proposal section. Best regards Tim Düsterhus
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
On Sun, Mar 10, 2024 at 2:38 AM Jim Winstead wrote: > > On Sat, Mar 9, 2024, at 1:04 PM, Bruce Weirdan wrote: > > On Sat, Mar 9, 2024, 20:46 Jim Winstead wrote: > >> If the adherence to semantic versioning is meant to be strict, > > > > PHP doesn't follow semver and never had. > > Okay, strike that and replace it with "adherence to the documented release > process" which says that backward compatibility can only be broken in a > release where the first digit in the version number is incremented. Which is effectively semver, so... see above. It's not that semver (or that documented release process) is bad or unsuitable. It's just that particular part about BC guarantees hasn't been followed for at least a decade now (see https://www.php.net/manual/en/migration83.php and preceding Migrating from ... documents). > It's been over three years since 8.0 was released, how long until any > backwards-incompatible changes are going to intentionally make it into > another release? Until the next minor release, which lately have been happening close to the end of a year. -- Best regards, Bruce Weirdan mailto:weir...@gmail.com
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
On Sat, Mar 9, 2024, at 1:04 PM, Bruce Weirdan wrote: > Hi Jim > > On Sat, Mar 9, 2024, 20:46 Jim Winstead wrote: >> If the adherence to semantic versioning is meant to be strict, > > PHP doesn't follow semver and never had. Okay, strike that and replace it with "adherence to the documented release process" which says that backward compatibility can only be broken in a release where the first digit in the version number is incremented. https://github.com/php/policies/blob/main/release-process.rst Which leaves my point intact, which is that voting which version to put backwards-incompatible changes in is a weird way to conform to the release process. It's been over three years since 8.0 was released, how long until any backwards-incompatible changes are going to intentionally make it into another release? Thanks. Jim
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
Hi Jim On Sat, Mar 9, 2024, 20:46 Jim Winstead wrote: > If the adherence to semantic versioning is meant to be strict, PHP doesn't follow semver and never had.
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
On Sat, Mar 9, 2024, at 5:07 AM, Jakub Zelenka wrote: > On Fri, Mar 8, 2024 at 6:30 PM Jim Winstead wrote: >> On Fri, Mar 8, 2024, at 12:12 AM, Hans Henrik Bergan wrote: >> > On Tue, 5 Mar 2024 at 20:17, Larry Garfield wrote: >> >> >> >> A 3 way up-down vote doesn't make sense. What happens if none of the 3 >> >> options reaches 66%? >> >> >> >> The viable options here are a single RCV vote (which we've done before), >> >> or a single "Should we do this" vote that requires 66%, followed by a >> >> "when should we do this" vote with 2 options, majority wins. >> >> >> >> --Larry Garfield >> > >> > Does this work for you guys? >> >> This is a lot of votes for a set of pretty simple changes with minimal BC >> implications, and maybe there's precedent for it but I don't like voting >> about what version to make particular changes in. Adding a language feature >> like property hooks is a one-vote RFC but fixing sleep() to take/return >> floats and work consistently cross-platform is somehow a six-vote ballot? Is >> there anyone who has indicated in any way that they would vote against >> making all three changes because one of the three is somehow unacceptable? >> What if #3 fails but not #1? > > I agree that there's a clear dependency on #1 (other way round than the above > actually... :) ). It might make more sense to do #1 as a primary vote and > then the rest as a secondary votes. I think it makes sense to have more votes > in this case as each thing has its own consideration and BC impact which is > primary difference compare to hooks RFC. Yeah, I got my example a little backwards, but either way is pretty goofy. >> And I'd say leave it up to the release managers to decide what version it is >> appropriate for the PR implementing an approved RFC go into. Micro-managing >> that by voting does not sit well with me. > > RM has no power to decide about features going in before the first beta. You > would need to update the policies to explicitly give RM such power. Voting is > currently the only way we have to decide such thing if there is no clear > agreement which I think wasn't the case in the PR's proposed for this. This may be a dumb question, but what's the process for determining whether the next significant release of PHP will be a minor version or a major version? If the adherence to semantic versioning is meant to be strict, it doesn't make any sense to vote on what version something like belongs to, because then you're saying that whether a BC break is significant enough to merit an increase to the major version is up for vote. I guess what I'm saying is that one way to deal with it if an RFC is a change that breaks backwards compatibility in any way, it can be passed at any time but the change only lands in whatever the next major version may be. So the RFC could have passed for this change to sleep() back before 8.1 was ever released and the change would just be waiting for the next release of a major version, subject to whatever process there is for deciding whether the next significant release is a major or minor version. (The way I think I would prefer is trusting the release managers to judge whether a BC break is significant enough to merit putting a change on ice until the next major version. Doing it by vote feels like excessive micro-management by voting, and doing it three times in one RFC for the sleep() function is bonkers.) Jim
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
On Fri, Mar 8, 2024 at 6:30 PM Jim Winstead wrote: > On Fri, Mar 8, 2024, at 12:12 AM, Hans Henrik Bergan wrote: > > On Tue, 5 Mar 2024 at 20:17, Larry Garfield > wrote: > >> > >> A 3 way up-down vote doesn't make sense. What happens if none of the 3 > options reaches 66%? > >> > >> The viable options here are a single RCV vote (which we've done > before), or a single "Should we do this" vote that requires 66%, followed > by a "when should we do this" vote with 2 options, majority wins. > >> > >> --Larry Garfield > > > > Does this work for you guys? > > This is a lot of votes for a set of pretty simple changes with minimal BC > implications, and maybe there's precedent for it but I don't like voting > about what version to make particular changes in. Adding a language feature > like property hooks is a one-vote RFC but fixing sleep() to take/return > floats and work consistently cross-platform is somehow a six-vote ballot? > Is there anyone who has indicated in any way that they would vote against > making all three changes because one of the three is somehow unacceptable? > What if #3 fails but not #1? > > I agree that there's a clear dependency on #1 (other way round than the above actually... :) ). It might make more sense to do #1 as a primary vote and then the rest as a secondary votes. I think it makes sense to have more votes in this case as each thing has its own consideration and BC impact which is primary difference compare to hooks RFC. > And I'd say leave it up to the release managers to decide what version it > is appropriate for the PR implementing an approved RFC go into. > Micro-managing that by voting does not sit well with me. > > RM has no power to decide about features going in before the first beta. You would need to update the policies to explicitly give RM such power. Voting is currently the only way we have to decide such thing if there is no clear agreement which I think wasn't the case in the PR's proposed for this. Regards Jakub
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
On Fri, Mar 8, 2024, at 12:12 AM, Hans Henrik Bergan wrote: > On Tue, 5 Mar 2024 at 20:17, Larry Garfield wrote: >> >> A 3 way up-down vote doesn't make sense. What happens if none of the 3 >> options reaches 66%? >> >> The viable options here are a single RCV vote (which we've done before), or >> a single "Should we do this" vote that requires 66%, followed by a "when >> should we do this" vote with 2 options, majority wins. >> >> --Larry Garfield > > Does this work for you guys? This is a lot of votes for a set of pretty simple changes with minimal BC implications, and maybe there's precedent for it but I don't like voting about what version to make particular changes in. Adding a language feature like property hooks is a one-vote RFC but fixing sleep() to take/return floats and work consistently cross-platform is somehow a six-vote ballot? Is there anyone who has indicated in any way that they would vote against making all three changes because one of the three is somehow unacceptable? What if #3 fails but not #1? And I'd say leave it up to the release managers to decide what version it is appropriate for the PR implementing an approved RFC go into. Micro-managing that by voting does not sit well with me. Jim
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
On Fri, Mar 8, 2024, at 8:12 AM, Hans Henrik Bergan wrote: > On Tue, 5 Mar 2024 at 20:17, Larry Garfield wrote: >> >> A 3 way up-down vote doesn't make sense. What happens if none of the 3 >> options reaches 66%? >> >> The viable options here are a single RCV vote (which we've done before), or >> a single "Should we do this" vote that requires 66%, followed by a "when >> should we do this" vote with 2 options, majority wins. >> >> --Larry Garfield > > Does this work for you guys? > > = Proposed Voting Choices = > > ### 1. Enhancement of Precision: Float Arguments for Sub-Second Precision > > **Should we extend `sleep()` to accept floats for sub-second delays?** > - Yes > - No > > **Which PHP version should implement this feature if accepted?** > - 8.4 > - 9.0 > > ### 2. Normalized Return Values on Windows > > **Should we modify `sleep()` on Windows for consistent return values?** > - Yes > - No > > **Which PHP version should implement this feature if accepted?** > - 8.4 > - 9.0 > > ### 3. Enhanced Return Value Precision > > **Should we increase `sleep()` return value precision to include > fractions of a second?** > - Yes > - No > > **Which PHP version should implement this feature if accepted?** > - 8.4 > - 9.0 > > @Tim >>adding a short *nix explanation of when sleep will > return earlier than expected would be helpful > > Where should that be? in the "Introduction" section? or the "Proposal" > section? (or elsewhere?) That seems reasonable, yes, assuming you want the change broken up into 3 votes. I haven't actually looked at the RFC itself in detail to say if that's wise or not. Do things still work if any given subset passes but not others? Generally you would put the above into the Voting section, with a text note saying that the main votes are 2/3 and the "When" votes are 50/50. Then structure the RFC so that it breaks into 3 pieces naturally, and note in the introduction that there's 3 related changes under consideration. --Larry Garfield
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
On Tue, 5 Mar 2024 at 20:17, Larry Garfield wrote: > > A 3 way up-down vote doesn't make sense. What happens if none of the 3 > options reaches 66%? > > The viable options here are a single RCV vote (which we've done before), or a > single "Should we do this" vote that requires 66%, followed by a "when should > we do this" vote with 2 options, majority wins. > > --Larry Garfield Does this work for you guys? = Proposed Voting Choices = ### 1. Enhancement of Precision: Float Arguments for Sub-Second Precision **Should we extend `sleep()` to accept floats for sub-second delays?** - Yes - No **Which PHP version should implement this feature if accepted?** - 8.4 - 9.0 ### 2. Normalized Return Values on Windows **Should we modify `sleep()` on Windows for consistent return values?** - Yes - No **Which PHP version should implement this feature if accepted?** - 8.4 - 9.0 ### 3. Enhanced Return Value Precision **Should we increase `sleep()` return value precision to include fractions of a second?** - Yes - No **Which PHP version should implement this feature if accepted?** - 8.4 - 9.0 @Tim >adding a short *nix explanation of when sleep will return earlier than expected would be helpful Where should that be? in the "Introduction" section? or the "Proposal" section? (or elsewhere?)
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
Hi On 3/5/24 14:09, Hans Henrik Bergan wrote: I don't want to spend too much effort on nitpicks, but if someone volunteers to improve it, I'd be happy to add it, in which case please send a PR to https://github.com/divinity76/stuff/blob/phprfc/2024/sleep_function_float_support.md To set my email in context: For me visuals play an important role in the overall presentation of an RFC. If it's not properly formatted, it's harder to read and harder to understand the RFC. Proper formatting also is some indicator that the author actually cares about the RFC instead of just throwing stuff over the fence and letting others figure out the details. This one is simple enough and it's certainly not something that makes me vote “No” out of spite, but perhaps this is something to keep in mind for future RFCs. For (2) it would help if you'd explain what it means for sleep() to be interrupted and how this can happen. I believe this is signal-handling related, but writing it out explicitly for the folks that didn't yet encounter it would probably make sense. I'm not an expert, but when researching this on Windows 10 + PHP 8.3.2, […] I don't know how to make it return 192 on Windows.. Anyone know? My remark was not just about Windows (I can't advice here either, I don't do Windows), adding a short *nix explanation of when sleep will return earlier than expected would be helpful as well. That's likely the more common case anyway. I'd just put a single "Do all of this in the next minor" vote there. All of the suggested improvements make sense to me and the breaking changes are mostly theoretical. meh, I don't want to risk the RFC getting rejected because too many people thought it should be done in next.major instead of next.minor, let's keep both next.minor + next.major vote options. (You're probably right, I predict a majority vote for next.minor for all 3, but i'll keep the vote options just in case.) Complicated voting options also risk the RFC getting rejected, especially if certain combinations of voting options are non-sense (such as 1: yes, 2: yes, 3: no). Personally I'd rather have no change at all, instead of a half-baked internally inconsistent change. Don't forgot to open up a dedicated explicit discussion thread once you move it into the "Discussion" phase. How would I even do that? Linking to https://externals.io/message/122388 isn't sufficient? Once you are happy with the RFC contents, instead of replying to this existing thread, send a fresh email to the list, titled "RFC: Support for Floats in Sleep Function", in there link the RFC and this discussion thread and say that the discussion period is starting now. This will ensure it will pop up as a fresh email for the folks who already ignored the subthread, because they were not interested in the pre-RFC discussion while stuff is still in flux. Best regards Tim Düsterhus
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
On Tue, Mar 5, 2024, at 1:09 PM, Hans Henrik Bergan wrote: > Voting has now been simplified to 3x no/php 8.4/php 9.0 questions. > (I actually would've preferred the original 6, would have been > unambiguous if people are supposed to checkbox only 8.4 or both 8.4 > and 9.0, and would have been easier to see the % of people who voted > only 9.0, I think. But I don't care enough about it to actually fight > for it, and multiple people requested it be reduced to 3, so let's go > with that :) ) > >>That said, thanks for making this, it's something I'd like to see in PHP as >>well. > > Happy to hear it :) > > >> - Instead of using backticks, use `sleep()` for inline and > `…` for multi-line snippets. This comes with syntax > highlighting and documentation links. >>(...) >> - It would help readability if you'd use additional headlines for each > of the three sub-proposals within the Proposal section. >> > > I don't want to spend too much effort on nitpicks, but if someone > volunteers to improve it, I'd be happy to add it, in which case please > send a PR to > https://github.com/divinity76/stuff/blob/phprfc/2024/sleep_function_float_support.md > >> For (2) it would help if you'd explain what it means for sleep() to be > interrupted and how this can happen. I believe this is signal-handling > related, but writing it out explicitly for the folks that didn't yet > encounter it would probably make sense. > > I'm not an expert, but when researching this on Windows 10 + PHP 8.3.2, > I couldn't actually get it to return 192. (nor return anything except 0): > - When sending a WM_CLOSE message (equivalent to `taskkill /IM > php.exe`), it was just completely ignored: PHP kept sleeping. > - When doing a TerminateProcess() call (equivalent to `taskkill /IM > php.exe /F`), PHP was just terminated, sleep never returned. > - When sending a CTRL_C_EVENT (equivalent to ctrl+C), PHP just > terminated, sleep never returned. > - When sending a CTRL_BREAK_EVENT (equivalent to ctrl+Break), PHP just > terminated, sleep never returned. > > I don't know how to make it return 192 on Windows.. Anyone know? > >>For the "Unaffected PHP Functionality" you could just spell out that anything >>that is not the sleep() function will be unaffected > > meh, someone else pointed out that the irrelevant sections could be > removed, I removed the "Unaffected PHP Functionality" section (along > with 2-3 others) > >> I'd just put a single "Do all of this in the next minor" vote there. All >>of the suggested improvements make sense to me and the breaking changes >>are mostly theoretical. > > meh, I don't want to risk the RFC getting rejected because too many > people thought it should be done in next.major instead of next.minor, > let's keep both next.minor + next.major vote options. (You're probably > right, I predict a majority vote for next.minor for all 3, but i'll > keep the vote options just in case.) A 3 way up-down vote doesn't make sense. What happens if none of the 3 options reaches 66%? The viable options here are a single RCV vote (which we've done before), or a single "Should we do this" vote that requires 66%, followed by a "when should we do this" vote with 2 options, majority wins. --Larry Garfield
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
Voting has now been simplified to 3x no/php 8.4/php 9.0 questions. (I actually would've preferred the original 6, would have been unambiguous if people are supposed to checkbox only 8.4 or both 8.4 and 9.0, and would have been easier to see the % of people who voted only 9.0, I think. But I don't care enough about it to actually fight for it, and multiple people requested it be reduced to 3, so let's go with that :) ) >That said, thanks for making this, it's something I'd like to see in PHP as >well. Happy to hear it :) > - Instead of using backticks, use `sleep()` for inline and `…` for multi-line snippets. This comes with syntax highlighting and documentation links. >(...) > - It would help readability if you'd use additional headlines for each of the three sub-proposals within the Proposal section. > I don't want to spend too much effort on nitpicks, but if someone volunteers to improve it, I'd be happy to add it, in which case please send a PR to https://github.com/divinity76/stuff/blob/phprfc/2024/sleep_function_float_support.md > For (2) it would help if you'd explain what it means for sleep() to be interrupted and how this can happen. I believe this is signal-handling related, but writing it out explicitly for the folks that didn't yet encounter it would probably make sense. I'm not an expert, but when researching this on Windows 10 + PHP 8.3.2, I couldn't actually get it to return 192. (nor return anything except 0): - When sending a WM_CLOSE message (equivalent to `taskkill /IM php.exe`), it was just completely ignored: PHP kept sleeping. - When doing a TerminateProcess() call (equivalent to `taskkill /IM php.exe /F`), PHP was just terminated, sleep never returned. - When sending a CTRL_C_EVENT (equivalent to ctrl+C), PHP just terminated, sleep never returned. - When sending a CTRL_BREAK_EVENT (equivalent to ctrl+Break), PHP just terminated, sleep never returned. I don't know how to make it return 192 on Windows.. Anyone know? >For the "Unaffected PHP Functionality" you could just spell out that anything >that is not the sleep() function will be unaffected meh, someone else pointed out that the irrelevant sections could be removed, I removed the "Unaffected PHP Functionality" section (along with 2-3 others) > I'd just put a single "Do all of this in the next minor" vote there. All >of the suggested improvements make sense to me and the breaking changes >are mostly theoretical. meh, I don't want to risk the RFC getting rejected because too many people thought it should be done in next.major instead of next.minor, let's keep both next.minor + next.major vote options. (You're probably right, I predict a majority vote for next.minor for all 3, but i'll keep the vote options just in case.) >I don't think I've ever seen anything using the return value of sleep(). same here. >Don't forgot to open up a dedicated explicit discussion thread once you move >it into the "Discussion" phase. How would I even do that? Linking to https://externals.io/message/122388 isn't sufficient?
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
Hi On 2/26/24 12:26, Hans Henrik Bergan wrote: Made a RFC draft: https://wiki.php.net/rfc/sleep_function_float_support First time, so I'm not surprised if there are some mistakes there. Thank you for the RFC. I have some suggestions to improve the readibility within the Wiki, as Markdown doesn't really render well there. The documentation is here: https://wiki.php.net/wiki/syntax - Instead of using backticks, use `sleep()` for inline and `…` for multi-line snippets. This comes with syntax highlighting and documentation links. - It would help readability if you'd use additional headlines for each of the three sub-proposals within the Proposal section. Regarding the contents: For (2) it would help if you'd explain what it means for sleep() to be interrupted and how this can happen. I believe this is signal-handling related, but writing it out explicitly for the folks that didn't yet encounter it would probably make sense. For the "Unaffected PHP Functionality" you could just spell out that anything that is not the sleep() function will be unaffected and more specifically any code that does not currently emit a deprecation is most likely unaffected. Regarding the voting options, I agree with Ayesh that 6 votes is too many. I'd even say it's 5 votes too many, instead of 3 votes to many. I'd just put a single "Do all of this in the next minor" vote there. All of the suggested improvements make sense to me and the breaking changes are mostly theoretical. I don't think I've ever seen anything using the return value of sleep(). Furthermore it doesn't make sense to accept (1), but not accept (3), as that would result in somewhat inconsistent behavior as you cannot $sleep = somefloat; while (($sleep = sleep($sleep)); to sleep for that exact somefloat value in the face of interrupts. Simple RFC, simple voting choice. Lastly, I see that the RFC still is in Draft stage. Don't forgot to open up a dedicated explicit discussion thread once you move it into the "Discussion" phase. Best regards Tim Düsterhus
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
> > Made a RFC draft: https://wiki.php.net/rfc/sleep_function_float_support > > First time, so I'm not surprised if there are some mistakes there. > > Feedback is very welcome. > Hi Hans, The RFC looks great, and I am personally positive to see these proposed changes implemented in PHP. One suggestion I have is to simplify the six votes to three, each with three options: - Disagree the proposal - Agree to implement in PHP 8.4 - Agree to implement in PHP 9.0 I think it's also helpful if the PR link was added to the top of the RFC, ideally next to the "First Published at". Most RFCs also remove the sections that don't apply to them (such as Future Scope section). That said, thanks for making this, it's something I'd like to see in PHP as well.
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
Made a RFC draft: https://wiki.php.net/rfc/sleep_function_float_support First time, so I'm not surprised if there are some mistakes there. Feedback is very welcome. I have tried sending this email 4 times over 2 days from hans at loltek dot net and every time the email server said delivery failed... So trying from an alternative email address..
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
On Fri, 16 Feb 2024 at 09:36, Alexandru Pătrănescu wrote: > > > On Fri, Feb 16, 2024 at 10:18 AM Hans Henrik Bergan wrote: >> >> Can we make sleep accept int|float? >> Made a PR: https://github.com/php/php-src/pull/13401 >> >> For years when I wanted to sleep for 0.1 seconds, it annoyed me that I >> couldn't do >> `sleep(0.1);` >> instead I had to do >> `usleep(figure out how many microseconds there are in 0.1 seconds and put it >> here);` >> > > Based on previous discussions https://externals.io/message/111448 > it seems the desired way was for a RFC to be created for this change, as it > involves some small changes that break BC. > > There is also the PR done by Michael Voříšek from 3.5 years ago where some > technical discussions took place: > https://github.com/php/php-src/pull/5961 > > Regards, > Alex > Interesting indeed. I implemented some improvements from that PR now (higher precision sleep and fixing the windows 192-issue), and got Michael Voříšek's attention :) also applied for RFC Karma. On Fri, 16 Feb 2024 at 14:20, Claude Pache wrote: > > Hi, > > > FWIW Python's `time.sleep` also works like this: > https://docs.python.org/3/library/time.html#time.sleep > > > Python also implements the following: > > If the sleep is interrupted by a signal and no exception is raised by the > signal handler, the sleep is restarted with a recomputed timeout. > > > I think we should also implement that. As a consequence, `sleep(...)` will > always return `0`. > > If we “fix” sleep(), let’s “fix” it completely. > > —Claude it seems we already have a function for that, it's called `time_sleep_until()`, quoting the documentation >Note: All signals will be delivered after the script wakes up. in contrast to normal sleep() that is signal interruptible. Sorry, I'm not interested in making sleep() uninterruptible, at least not until after I get int|float accepted upstream.
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
On Fri, Feb 16, 2024 at 10:18 AM Hans Henrik Bergan wrote: > Can we make sleep accept int|float? > Made a PR: https://github.com/php/php-src/pull/13401 > > For years when I wanted to sleep for 0.1 seconds, it annoyed me that I > couldn't do > `sleep(0.1);` > instead I had to do > `usleep(figure out how many microseconds there are in 0.1 seconds and put > it here);` > > Based on previous discussions https://externals.io/message/111448 it seems the desired way was for a RFC to be created for this change, as it involves some small changes that break BC. There is also the PR done by Michael Voříšek from 3.5 years ago where some technical discussions took place: https://github.com/php/php-src/pull/5961 Regards, Alex
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
Hi, > > FWIW Python's `time.sleep` also works like this: > https://docs.python.org/3/library/time.html#time.sleep Python also implements the following: > If the sleep is interrupted by a signal and no exception is raised by the > signal handler, the sleep is restarted with a recomputed timeout. > I think we should also implement that. As a consequence, `sleep(...)` will always return `0`. If we “fix” sleep(), let’s “fix” it completely. —Claude
[PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
Can we make sleep accept int|float? Made a PR: https://github.com/php/php-src/pull/13401 For years when I wanted to sleep for 0.1 seconds, it annoyed me that I couldn't do `sleep(0.1);` instead I had to do `usleep(figure out how many microseconds there are in 0.1 seconds and put it here);` FWIW Python's `time.sleep` also works like this: https://docs.python.org/3/library/time.html#time.sleep
