Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123383 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 865E71A009C for ; Tue, 21 May 2024 15:59:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1716307254; bh=uNKtQPNo+p9myFv+Z/k3of842LAijP+sYVDWlT6MsTQ=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=SsJzLKr+FN14+OFXmCg1LvsRfjCv+reeG4D+8N4DhivT1XchV4MGEj44fSPfUf4Xd MzYdzwRyg8cs/vyNoZphHTZRAWtLyVYYoACQOcpj/+3COBdl9P6nOtkchUl3l3BimM o4ngmY8IcWhzTYTYq4bSnIMWLQ9fPwoQOK0kh52nIOQo1ixW2Eo8zyJwvmnYgfFCun zIDs5TKpHNZjD2jwV5q5HO/cNmyzV9MNpAB6U4+avhAu9m7XDuSP8jUMeWFiNMqPHf oXI0UVQ0uYzFm0ieSd0YzxjIxZ2QTY6eEZgdWn1Ht+bufyYA6etkwI8M2ZLWOQtNEY 4krO/Ui40E5+g== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 0D64D180081 for ; Tue, 21 May 2024 16:00:53 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from wfout6-smtp.messagingengine.com (wfout6-smtp.messagingengine.com [64.147.123.149]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 21 May 2024 16:00:52 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfout.west.internal (Postfix) with ESMTP id B2F6A1C0013E; Tue, 21 May 2024 11:59:55 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute1.internal (MEProxy); Tue, 21 May 2024 11:59:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm2; t=1716307195; x= 1716393595; bh=uNKtQPNo+p9myFv+Z/k3of842LAijP+sYVDWlT6MsTQ=; b=b hiWdfxkKWT36qABuWSmAI9HxQ2OyiIlOosvHLy/I91O+1Za1BnNVLBVNIP6Z1IXD DrOmAMD5HjN/a0vNCUjVUjbi1lCabaX5puxOdo6d9fm4+H+lX+HVcjKpr8AM5Jox Z+3pgGxESd2aoXSgIAVF1VKln+e11npv0+avB0ldu+bvXnj0ab9O4anKl9eoqsNE 6ufpi+NGhQkbLcL8Ss1rw+GasMan+JNLM9bAnfmGBxmIy5ttb1/6radEOd99kI0u sh+kM7Id03j/wEhMzKI4d8blLCppiWom6TMp78+7iIxsFYfrc4LKKObDDzgVC1dX waHGzbEkRwFHK9S1maTyw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1716307195; x=1716393595; bh=uNKtQPNo+p9myFv+Z/k3of842LAi jP+sYVDWlT6MsTQ=; b=FV4oGW3B3cH24BRJSWB2HDcRAZB5TzzgJnhAznqFP1tM 630hGGZcPDCTV4vDcFCJOSJlFP35eB//M8nBp1tzcxdMZoNDHG241KhPVqV4MkIi Vc+vHeA7/lczyjxeOHCJUr884n84vHJzfjWaMYq8YutWDYpZyEqIEBgj7WPWd8ML 05tG+C0/hto6Y/olxpkW102yObS3Gf4k/wOl5xmf9HUAkRO0zVKUVaRiFXPRvKti cO1/Eitz9maQHryryAzXUWPzc0NjEjEWB/L8fwE4pYzEqku9n2VEhJ9oOcESqo45 EaZYJDAobr9EImtkUlM7o/cXucp1bCGcEW6ismxxYA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvdeivddgleefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerreejnecuhfhrohhmpedftfho sgcunfgrnhguvghrshdfuceorhhosgessghothhtlhgvugdrtghouggvsheqnecuggftrf grthhtvghrnhepvdekleethfdvffduveeutddtuddtleetgfeugfejfeehieejvdegjeeu ueefvefgnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrohgssegsohhtthhlvggurdgtohgu vghs X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id D2C0715A0093; Tue, 21 May 2024 11:59:54 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-480-g515a2f54a-fm-20240515.001-g515a2f54 Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 Message-ID: In-Reply-To: References: Date: Tue, 21 May 2024 17:59:34 +0200 To: "Arnaud Le Blanc" , "Rob Landers" Cc: "PHP internals" Subject: Re: [PHP-DEV] Switching max_execution_time from CPU time to wall-clock time and from SIGPROF to SIGALRM Content-Type: multipart/alternative; boundary=ffea226c680545edb1a8591b9ae33651 From: rob@bottled.codes ("Rob Landers") --ffea226c680545edb1a8591b9ae33651 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, May 21, 2024, at 14:39, Arnaud Le Blanc wrote: > Hi Robert, >=20 > > This sounds like a bug with Mac vs. a PHP issue. >=20 > 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. >=20 > > 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. >=20 > 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=E2=80=99m all in favor of w= all-clock time, personally. It=E2=80=99s much easier to reason about.=20 >=20 > > 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. >=20 > 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. >=20 > [1] https://github.com/apple-oss-distributions/xnu/blob/94d3b452840153= a99b38a3a9659680b2a006908e/bsd/kern/kern_time.c#L432 > [2] https://gist.github.com/arnaud-lb/012195a2fe4d3a2c1bff530a73ae6b11 >=20 > Best Regards, > Arnaud >=20 =E2=80=94 Rob --ffea226c680545edb1a8591b9ae33651 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable

=
On Tue, May 21, 2024, at 14:39, Arnaud Le Blanc wrote:
Hi Robert,

> This sounds like a bug with Mac vs. a PH= P issue.

This is what I believe as well. FW= IW 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 explici= tly) monotonic. ITIMER_REAL can go
> backwards (NTP clo= ck adjustments) which might have interesting
> side-eff= ects if the clock is adjusted.

Good point. = Do you have references about ITIMER_REAL using a
non-monot= onic 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 o= n that, and
we should use a better specified timer mechani= sm if we eventually
switch to wall-clock time on all platf= orms, but it seems reasonable as
a workaround for the ITIM= ER_PROF bug on MacOS/Apple Silicon.

That was my only concern. That being said, I=E2=80=99m all in favo= r of wall-clock time, personally. It=E2=80=99s much easier to reason abo= ut. 


> The problem might actually be using ITIMER_P= ROF, which "Measures CPU
> time used by the process, in= cluding both user space and kernel space"
> and usage o= f sockets/threads might give an "accelerated" value while
= > maybe ITIMER_VIRTUAL is the one we should be using since it "Measur= es
> CPU time used by the process (user space)" which w= on'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 consumi= ng a considerable
amount of resources.