On Tue, May 21, 2024, at 14:39, Arnaud Le Blanc wrote: > 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.
That was my only concern. That being said, I’m all in favor of wall-clock time, personally. It’s much easier to reason about. > > > 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 > — Rob
