Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123386
Precedence: bulk
MIME-Version: 1.0
References: <CAP1Jc10EHNhfCwz9p0tSyrSLiskCFnz7Ae0aTtYFJ8snYmVNOQ@mail.gmail.com>
In-Reply-To: <CAP1Jc10EHNhfCwz9p0tSyrSLiskCFnz7Ae0aTtYFJ8snYmVNOQ@mail.gmail.com>
Date: Tue, 21 May 2024 21:05:22 +0200
Message-ID: <CAEPJdumJdNRcd7OjCMD2s8DcAjhXEUUoxa8LkOqvHTxyNe=jJg@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: multipart/alternative; boundary="000000000000ac8ced0618fb809f"
From: kontakt@beberlei.de (=?UTF-8?Q?Benjamin_Au=C3=9Fenhofer?=)

--000000000000ac8ced0618fb809f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 17, 2024 at 3:49=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
>

For reference: There is also this RFC for max_execution_wall_time that was
discussed four years ago. https://externals.io/message/112492#112492

--000000000000ac8ced0618fb809f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Fri, May 17, 2024 at 3:49=E2=80=AF=
PM Arnaud Le Blanc &lt;<a href=3D"mailto:arnaud.lb@gmail.com">arnaud.lb@gma=
il.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;borde=
r-left-color:rgb(204,204,204);padding-left:1ex">Hi internals,<br>
<br>
There is an issue with max_execution_time on MacOS, probably only<br>
MacOS 14 on Apple Silicon, that causes timeouts to fire too early [1].<br>
max_execution_time is implemented with setitimer(ITIMER_PROF) on this<br>
platform, and the SIGPROF signal is delivered too early for some<br>
reason. Switching to ITIMER_REAL appears to fix the issue, and Manuel<br>
Kress opened a PR [3].<br>
<br>
Are there objections against switching to ITIMER_REAL on MacOS (Apple<br>
Silicon only) in all currently supported PHP versions? (next 8.2.x,<br>
8.3.x, 8.x)<br>
<br>
Apart from fixing the issue, this would introduce the following minor<br>
breaking changes:<br>
<br>
- max_execution_time on MacOS would be based on wall-clock time rather<br>
than CPU time, so the time spent in I/O, sleep(), and syscalls in<br>
general would count towards the max_execution_time<br>
- The SIGALRM signal would be used instead of the SIGPROF signal<br>
(using SIGALRM conflicts with pcntl_alarm(), but SIGPROF conflicts<br>
with profilers). As noted by Dmitry, it also conflicts with sleep() on<br>
some platforms, however this should be safe on MacOS.<br>
<br>
Currently max_execution_time is based on wall-clock time on ZTS and<br>
Windows, and CPU time otherwise. On Linux and FreeBSD, wall-clock time<br>
can also be used when building with<br>
--enable-zend-max-execution-timers. M=C3=A1t=C3=A9 proposed to add a wall-c=
lock<br>
based timeout in the past [2] but the discussion has stalled. Any<br>
thoughts about eventually switching other platforms to wall-clock<br>
timeouts in the next 8.x ?<br>
<br>
TL;DR:<br>
- Any objection about using wall-clock max_execution_time and SIGALRM<br>
on MacOS Apple Silicon in all supported versions?<br>
- Thoughts about using wall-clock timeouts on all platforms in the next 8.x=
 ?<br>
<br>
[1] <a href=3D"https://github.com/php/php-src/issues/12814" rel=3D"noreferr=
er" target=3D"_blank">https://github.com/php/php-src/issues/12814</a><br>
[2] <a href=3D"https://github.com/php/php-src/pull/6504" rel=3D"noreferrer"=
 target=3D"_blank">https://github.com/php/php-src/pull/6504</a><br>
[3] <a href=3D"https://github.com/php/php-src/pull/13567" rel=3D"noreferrer=
" target=3D"_blank">https://github.com/php/php-src/pull/13567</a><br>
<br>
Best Regards,<br>
Arnaud<br></blockquote><div><br></div><div>For reference: There is also thi=
s RFC for max_execution_wall_time that was discussed four years ago. <a hre=
f=3D"https://externals.io/message/112492#112492">https://externals.io/messa=
ge/112492#112492</a></div><div><br></div><div><br></div></div></div>

--000000000000ac8ced0618fb809f--