Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123332
Precedence: bulk
MIME-Version: 1.0
References: <CAP1Jc10EHNhfCwz9p0tSyrSLiskCFnz7Ae0aTtYFJ8snYmVNOQ@mail.gmail.com>
In-Reply-To: <CAP1Jc10EHNhfCwz9p0tSyrSLiskCFnz7Ae0aTtYFJ8snYmVNOQ@mail.gmail.com>
Date: Fri, 17 May 2024 16:10:26 +0200
Message-ID: <CAPzBOBO9qmWajx_Vx25gVwHLPYq5Fom0Fnyxn06BrBDLfDyz4g@mail.gmail.com>
Subject: Re: [PHP-DEV] Switching max_execution_time from CPU time to
 wall-clock time and from SIGPROF to SIGALRM
To: Arnaud Le Blanc <arnaud.lb@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: landers.robert@gmail.com (Robert Landers)

On Fri, May 17, 2024 at 3:50=E2=80=AFPM Arnaud Le Blanc <arnaud.lb@gmail.co=
m> 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=C3=A1t=C3=A9 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