int|float for sleep? sleep(0.1) => sleep 0.1 seconds

1 year ago by Hans Henrik Bergan — view source

unread

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

1 year ago by drealecs@gmail.com — view source

unread

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

1 year ago by Claude Pache — view source

unread

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

1 year ago by Hans Henrik Bergan — view source

unread

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.

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.

1 year ago by Hans Henrik Bergan — view source

unread

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..

1 year ago by Ayesh Karunaratne — view source

unread

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.

1 year ago by tim@bastelstu.be — view source

unread

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 <php>sleep()</php> for inline and
<PHP>…</PHP> 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

1 year ago by Hans Henrik Bergan — view source

unread

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 <php>sleep()</php> for inline and
<PHP>…</PHP> 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?

1 year ago by Larry Garfield — view source

unread

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 <php>sleep()</php> for inline and
<PHP>…</PHP> 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

1 year ago by Hans Henrik Bergan — view source

unread

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?

Which PHP version should implement this feature if accepted?

2. Normalized Return Values on Windows

Should we modify sleep() on Windows for consistent return values?

Which PHP version should implement this feature if accepted?

3. Enhanced Return Value Precision

Should we increase sleep() return value precision to include
fractions of a second?

Which PHP version should implement this feature if accepted?

@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?)

1 year ago by Larry Garfield — view source

unread

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

1 year ago by Jim Winstead — view source

unread

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

1 year ago by Jakub Zelenka — view source

unread

On Tue, 5 Mar 2024 at 20:17, Larry Garfield larry@garfieldtech.com
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

1 year ago by Jim Winstead — view source

unread

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

1 year ago by Bruce Weirdan — view source

unread

Hi Jim

If the adherence to semantic versioning is meant to be strict,

PHP doesn't follow semver and never had.

1 year ago by Jim Winstead — view source

unread

Hi Jim

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

1 year ago by Bruce Weirdan — view source

unread

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:weirdan@gmail.com

1 year ago by Gina P. Banyard — view source

unread

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

1 year ago by tim@bastelstu.be — view source

unread

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

1 year ago by tim@bastelstu.be — view source

unread

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