Skip to content

Don't reset the timeout on deactivate when the timeout was changed #6683

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

NattyNarwhal
Copy link
Member

When the time limit for a script is changed, when the script ends, its INI value will be reset. This calls the event handler for the
timeout change, which will unset then reset the timeout. However, this is done even if the script is done executing, and say, the CGI or CLI web server process is idle.

This is probably incorrect, but isn't a problem on most platforms, because PHP uses a timer that only ticks when the process is active (that is, executing code). Since when it's idle, it's blocking on listen/read, it won't tick because nothing executes. However, on platforms where only the real-time timer is supported, (Cygwin/PASE) it ticks regardless of if PHP is even executing. This means that the idle processes are subject to timeouts from the INI reset on script end.

This makes it so the timer is never set if the state is deactivating. Testing with the CLI web server indicates the timer no longer
spuriously activates under PASE.

Fixes PHP bug #80728

When the time limit for a script is changed, when the script ends,
its INI value will be reset. This calls the event handler for the
timeout change, which will unset then reset the timeout. However,
this is done even if the script is done executing, and say, the CGI
or CLI web server process is idle.

This is probably incorrect, but isn't a problem on most platforms,
because PHP uses a timer that only ticks when the process is active
(that is, executing code). Since when it's idle, it's blocking on
listen/read, it won't tick because nothing executes. However, on
platforms where only the real-time timer is supported, (Cygwin/PASE)
it ticks regardless of if PHP is even executing. This means that the
idle processes are subject to timeouts from the INI reset on script
end.

This makes it so the timer is never set if the state is deactivating.
Testing with the CLI web server indicates the timer no longer
spuriously activates under PASE.

Fixes PHP bug #80728
@nikic
Copy link
Member

nikic commented Mar 16, 2021

cc @kocsismate

@nikic
Copy link
Member

nikic commented Mar 16, 2021

@kocsismate I think you tried to deal with this issue in as part of #6504, but in a more complicated way (extra skip_on_update flag?)

@NattyNarwhal
Copy link
Member Author

Ah, I didn't know wall time across all platforms was something that was being considered. A really simple implementation of that would probably be just collapse everything to the real-time timer instead, if you didn't mind completely changing semantics. As of right now, only i/Cygwin are doing it that way. (Which makes me realize I should probably make a note of that in the docs...)

@NattyNarwhal
Copy link
Member Author

Poking to see if this patch is still interesting in the wake of the other one. I'm also interested in the backporting policy; curious if this is OK for 7.4/8.0.

@NattyNarwhal
Copy link
Member Author

Hate to sound like a bother, but bumping. There's a feature freeze soon that might block the other PR, so if that PR gets blocked/declined, this one would at least keep the original behaviour consistent.

@nikic
Copy link
Member

nikic commented Jun 29, 2021

The alternative here would be to change the shutdown sequence and move zend_unset_timeout (currently stage 4) after zend_deactivate (currently stage 9). That means the timeout is active for larger parts of the shutdown sequence though, so I think your patch may be preferable as a more conservative approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants