On Fri, May 17, 2024 at 3:50 PM Arnaud Le Blanc <arnaud...@gmail.com> wrote: > > Hi internals, > > There is an issue with max_execution_time on MacOS, probably only > MacOS 14 on Apple Silicon, that causes timeouts to fire too early [1]. > max_execution_time is implemented with setitimer(ITIMER_PROF) on this > platform, and the SIGPROF signal is delivered too early for some > reason. Switching to ITIMER_REAL appears to fix the issue, and Manuel > Kress opened a PR [3]. > > Are there objections against switching to ITIMER_REAL on MacOS (Apple > Silicon only) in all currently supported PHP versions? (next 8.2.x, > 8.3.x, 8.x) > > Apart from fixing the issue, this would introduce the following minor > breaking changes: > > - max_execution_time on MacOS would be based on wall-clock time rather > than CPU time, so the time spent in I/O, sleep(), and syscalls in > general would count towards the max_execution_time > - The SIGALRM signal would be used instead of the SIGPROF signal > (using SIGALRM conflicts with pcntl_alarm(), but SIGPROF conflicts > with profilers). As noted by Dmitry, it also conflicts with sleep() on > some platforms, however this should be safe on MacOS. > > Currently max_execution_time is based on wall-clock time on ZTS and > Windows, and CPU time otherwise. On Linux and FreeBSD, wall-clock time > can also be used when building with > --enable-zend-max-execution-timers. Máté proposed to add a wall-clock > based timeout in the past [2] but the discussion has stalled. Any > thoughts about eventually switching other platforms to wall-clock > timeouts in the next 8.x ? > > TL;DR: > - Any objection about using wall-clock max_execution_time and SIGALRM > on MacOS Apple Silicon in all supported versions? > - Thoughts about using wall-clock timeouts on all platforms in the next 8.x ? > > [1] https://github.com/php/php-src/issues/12814 > [2] https://github.com/php/php-src/pull/6504 > [3] https://github.com/php/php-src/pull/13567 > > Best Regards, > Arnaud
This sounds like a bug with Mac vs. a PHP issue. That being said, the biggest issue between changing these clocks is that ITIMER_PROF is (practically, but not explicitly) monotonic. ITIMER_REAL can go backwards (NTP clock adjustments) which might have interesting side-effects if the clock is adjusted. The problem might actually be using ITIMER_PROF, which "Measures CPU time used by the process, including both user space and kernel space" and usage of sockets/threads might give an "accelerated" value while maybe ITIMER_VIRTUAL is the one we should be using since it "Measures CPU time used by the process (user space)" which won't count kernel timings. Robert Landers Software Engineer Utrecht NL
