Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123379
Precedence: bulk
MIME-Version: 1.0
References: <CAP1Jc10EHNhfCwz9p0tSyrSLiskCFnz7Ae0aTtYFJ8snYmVNOQ@mail.gmail.com>
 <CAPzBOBO9qmWajx_Vx25gVwHLPYq5Fom0Fnyxn06BrBDLfDyz4g@mail.gmail.com>
In-Reply-To: <CAPzBOBO9qmWajx_Vx25gVwHLPYq5Fom0Fnyxn06BrBDLfDyz4g@mail.gmail.com>
Date: Tue, 21 May 2024 14:39:01 +0200
Message-ID: <CAP1Jc10drH9UF=nVKfzC2wyqOoXCqjKGRFkkKKawg3hcEDT-Bg@mail.gmail.com>
Subject: Re: [PHP-DEV] Switching max_execution_time from CPU time to
 wall-clock time and from SIGPROF to SIGALRM
To: Robert Landers <landers.robert@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
From: arnaud.lb@gmail.com (Arnaud Le Blanc)

Hi Robert,

> This sounds like a bug with Mac vs. a PHP issue.

This is what I believe as well. FWIW I was able to reproduce the issue
outside of PHP [2]. I've reported the bug to Apple, but I don't expect
it to be fixed quickly, if at all.

> 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.

Good point. Do you have references about ITIMER_REAL using a
non-monotonic clock, besides the lack of specification regarding the
clock? Based on experiments and the code [1], I think that ITIMER_REAL
uses a monotonic clock on MacOS. It's not ideal to rely on that, and
we should use a better specified timer mechanism if we eventually
switch to wall-clock time on all platforms, but it seems reasonable as
a workaround for the ITIMER_PROF bug on MacOS/Apple Silicon.

> 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.

Unfortunately ITIMER_VIRTUAL is not really useful as a
max_execution_time implementation as it will basically never fire in a
syscall-heavy workload. E.g. after replacing ITIMER_PROF by
ITIMER_VIRTUAL in [2], the program runs for well over the specified
time before receiving a signal, despite consuming a considerable
amount of resources.

[1] https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153a99b38a3a9659680b2a006908e/bsd/kern/kern_time.c#L432
[2] https://gist.github.com/arnaud-lb/012195a2fe4d3a2c1bff530a73ae6b11

Best Regards,
Arnaud