opcache: fix revalidation in long running CLI scripts

[Sannis]

It looks like opcache was initially designed with short-lived requests in mind, so when checking if the file should be re-validated, the code uses 'request time' instead of 'now', where request time is calculated once on the script startup. Which basically means that in CLI this check will never succeed.

This PR containing the patch to fix this issue covered with a test that passes in this branch but not in PHP-8.3.
The issue itself is older, but I rebased the patch to PHP-8.3 as mentioned in CONTRIBUTING doc.

Not sure if I must fill the issue separately, but will be happy to do if needed.

[dstogov]

Technically the patch looks OK and the general idea makes sense.

However, the original behavior also makes sense for the most use cases and for the "static" CLI apps the new behaviour would introduce useless gettimeofday syscalls.

Instead of the new behavior for CLI mode only, I would think about consistent landing of this future in general. For example, we may define a new special opcache.revalidate_freq=-1 setting.

[Sannis]

Hi @dstogov,

Thank you for taking the time to review the patch and for the thoughtful feedback.

I may have misread your suggestion to use opcache.revalidate_freq = -1. In today’s logic a non-positive value means “revalidate on every compile”, which effectively disables the interval check entirely. My goal is slightly different: I’d like to keep the existing period logic while simply advancing the reference time inside long-running CLI processes.

To achieve that without overloading revalidate_freq, would you be open to adding a dedicated switch, e.g.

; 0 = current behaviour (reference time fixed per process / request)
; 1 = dynamic reference time (re-evaluated on every include/require)
opcache.revalidate_use_dynamic_time = 0

Default would remain 0 for all SAPIs, preserving today’s behaviour; setting it to 1 would enable the new moving-window logic while still honouring revalidate_freq. In this case I can remove SAPI check in the patch as this may be controllable through separate php-cli.ini.

If this sounds acceptable I’ll update the patch, add the new ini entry to both development and production templates, and ping you for another look.

Thanks again for your guidance!