Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:126417 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 EEC6C1A00BC for ; Fri, 14 Feb 2025 15:31:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1739546900; bh=fcFO+rnj9+/qeq3MGbEdBliSouNhxbCjPTGYLMPX9yY=; h=Date:From:To:In-Reply-To:References:Subject:From; b=gN2ePRPF5iUFkUdFfNUhErRQxLJ1PNdBwnSLUU7rEN0bQMCKxC033h14855nfEV7O yPMhDBeg9Po4AV3oF/J4g2CBHbYgYTBN4zS4It+6aiGT4zq7OldITRTD0cbYKOAlmw ztOKYnj0+LUAuP/x0c7Kp9j+OwI2v3GylEf+bH0dShO9XWhUHdAfYGQTtHFlFPl95A bL4iAQs8Gb4vDMljcISHe81R4aNm3Vjo59GR5CJe9kmLZ7Cp0e14UlxB6T8Lzj1X7L bdNIGUznBjIVwXWhg0R9pCnB6buJ8e0fQW5/scGw88EsMdCBaL846gfPOBZouad6tx LfHLfAl7pbC/g== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A01AD18006D for ; Fri, 14 Feb 2025 15:28:17 +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.9 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from fhigh-a5-smtp.messagingengine.com (fhigh-a5-smtp.messagingengine.com [103.168.172.156]) (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 ; Fri, 14 Feb 2025 15:28:15 +0000 (UTC) Received: from phl-compute-13.internal (phl-compute-13.phl.internal [10.202.2.53]) by mailfhigh.phl.internal (Postfix) with ESMTP id EC7B01140163 for ; Fri, 14 Feb 2025 10:30:57 -0500 (EST) Received: from phl-imap-09 ([10.202.2.99]) by phl-compute-13.internal (MEProxy); Fri, 14 Feb 2025 10:30:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=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=fm1; t=1739547057; x=1739633457; bh=FLXYV/VQPZ TepKxyGFbmly8XLARjSd1ylI0eV1QT7Js=; b=c9bTzFLX3GsKYUv0h+PdkoyzDm g+uoEg0f18DwmrjjCV03AWHZlJxwwoyNJghzywO5D51Vm3DhuzfdGjnVMwG2kJhx G4XLcVnp/DYeN9Xi7Rs/L096UC133FgI1O+Lrugp7vIfSIqw8u6XeUX2WrydDtVr aknY9rIinvF3chHEP+UtghOlBaAIm0N0yxna+7YpzSJSMTBm6MNi0RBCAf4Rt99Y LhHaOzFrM8PZphVKmO3C7AlXMDsSU6Vm02tmmGInnWUs9j+RahG76vNnbyQug590 yQhDWDS9hNrHlTZzGlmQrgX/c//oeeHYcZw2V65RsxtkOahsx8L8tQbMtqrw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1739547057; x=1739633457; bh=FLXYV/VQPZTepKxyGFbmly8XLARjSd1ylI0 eV1QT7Js=; b=yL3ZOen4r1SCSLAd/m/x+vb0DiTLI5ffwzX1opFJE50q15JcuMU yizpy45YEbdkk5fHuuDY4CvENI9hFb7JRgtnjxEGuZ333Iv7YCWg1vkglF+vstVj LMsPgFmbwjKwfb0kaFMNjMjyep6QuNBmFuHWwq49gJSCsrWve15GBOmmW0ESWBZI puZ9DimWY3ondTWQUFuwLUV4Ks3t/M+4sB+AHgj0JGERiJd8MlLZrkPtm9NZ3473 BMaXlPNz2dU0EaqFEgTMols3jGtWE1uPHFyaM3MBbZOCiG+Dnuxr4b++0J5k+VfH 8W/6PSZjMw2/l+wbvV2qjWLnxZZlR8aeVXg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdehtddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepofggff fhvffkjghfufgtsegrtderreertdejnecuhfhrohhmpedftfhosgcunfgrnhguvghrshdf uceorhhosgessghothhtlhgvugdrtghouggvsheqnecuggftrfgrthhtvghrnhepjeduhf elgeefleeuiefgvedugffgleeukefhjeehvdfgtdetheehieeuieefieelnecuffhomhgr ihhnpehphhhprdhnvghtpdgvgihtvghrnhgrlhhsrdhiohenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrohgssegsohhtthhlvggurdgtohgu vghspdhnsggprhgtphhtthhopedupdhmohguvgepshhmthhpohhuthdprhgtphhtthhope hinhhtvghrnhgrlhhssehlihhsthhsrdhphhhprdhnvght X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id B22CA780068; Fri, 14 Feb 2025 10:30:57 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 Date: Fri, 14 Feb 2025 16:30:37 +0100 To: internals@lists.php.net Message-ID: In-Reply-To: References: Subject: Re: [PHP-DEV] PHP True Async Content-Type: multipart/alternative; boundary=1eb4f71e92cc402eadb7bbd83074baf7 From: rob@bottled.codes ("Rob Landers") --1eb4f71e92cc402eadb7bbd83074baf7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 14, 2025, at 16:18, Edmond Dantes wrote: > > Yeah we are actually planning better API for this supporting epoll = and kqueu which is long over due. There are other use cases for this so = hopefully it will get prioritised soon. > Oh, it would be absolutely great if PHP used a better abstraction fo= r I/O waiting! >=20 > > You could still achieve this in extensions. But if you really wanted= to have some main part, then it should rather go to main/ like streams = and other similar stuff.=20 > Of course, this will need some thought. >=20 >> I have got some additional feedback from our discussion that we jus= t had with the PHP foundation devs. *It was that it looks like an async/= await implementation with fiber switching which is something that was ex= plicitly decided not to be done in fibers RFC* - https://wiki.php.net/rf= c/fibers (read FAQ). The reasoning was that this should be done in user = space. So you should properly describe in the RFC what this offers compa= re to user space variants (revolt/react/amp). There were also some conce= rns that it would makes things harder to debug in internal implementatio= n so this should be also addressed in the RFC. It should be noted that F= ibers RFC did not preclude introduction of such extensions to the core b= ut you will likely need describe it in the RFC and show that there are g= ood reasons to include. >=20 > Unfortunately, I don=E2=80=99t know much about what happened during th= e adoption of Fibers, but I remember that the situation was not ideal. I= don=E2=80=99t know why that decision was made. >=20 > For me, as a developer, the ultimate criterion is the code itself. If = a solution makes the code better, simpler, and reduces the number of lin= es, then it=E2=80=99s a good solution. If a solution forces developers t= o repeatedly write the same boilerplate code, including entire MySQL/Pos= tgreSQL drivers, then I can=E2=80=99t consider it a rational decision fr= om a development perspective=E2=80=94though, of course, there could be o= ther reasons, such as financial constraints or lack of resources. Or loo= k at Swoole=E2=80=94it has to override dozens of PHP functions. Even wor= se, it recently started literally copying entire extensions just for a f= ew lines of code... This does not look like a "good solution." >=20 > AMPHP and Revolt are talented projects, but they are not part of the l= anguage itself. This means that PHP extensions cannot call user-mode cod= e and rely on it as a standard, unlike how Rust extensions do. Of course= , from C, you can call any user-mode function, but that doesn't seem lik= e the right approach. Especially since PHP is a high-level language, whi= ch imposes a responsibility for consistency in its paradigm. >=20 > Regarding debugging=E2=80=94over the past three years, there have been= no debugging issues with AMPHP. Consequently, there shouldn=E2=80=99t b= e any, since this project does not modify the Fiber mechanism itself. It= only extends it to make the tool more complete and fully functional. >=20 > And this is precisely the main reason why I=E2=80=99m writing these li= nes. As a PHP developer, I see that the language is not truly complete w= hen it comes to concurrent programming, and I am genuinely surprised tha= t this has not been addressed yet. How did this happen? >=20 > Have a nice day! >=20 > Ed. >=20 >=20 >>=20 I'm reminded of Rowan's comment here: Why did fibers get added to php co= re over something more fleshed out like swoole? - Externals (https://externals.io/message/121291#12= 1315) > Sometimes the answer to "why doesn't X do Y?" is just "because nobody'= s stepped forward to implement it yet"; sometimes it's "nobody's worked = out how to do it without breaking Z"; in which case, feel free to volunt= eer that time, or solve that issue. But, yes, sometimes it's "because we= had a long and tiring debate, and ended up with a compromise that nobod= y really likes"; or "because the lack of official leadership and a relat= ively high turnover of contributors makes us pretty bad at longer-term p= lanning". It pretty much sums it up (also, you can always search the mailing list = archives for previous discussions on these topics). =E2=80=94 Rob --1eb4f71e92cc402eadb7bbd83074baf7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

=
On Fri, Feb 14, 2025, at 16:18, Edmond Dantes wrote:
<= /div>
> =0A=0AYeah we are actually planning better = API for this supporting epoll and kqueu which is long over due. There ar= e other use cases for this so hopefully it will get prioritised soon.
  Oh, it would be absolutely great if PHP used a better= abstraction for I/O waiting!

> You coul= d still achieve this in extensions. But if you really wanted to have som= e main part, then it should rather go to main/ like streams and other si= milar stuff. 
  Of course, this will need some t= hought.

  I have got some additional feedba= ck from our discussion that we just had with the PHP foundation devs. It was that it looks like an async/await implementation with fiber swit= ching which is something that was explicitly decided not to be done in f= ibers RFC - https://wiki.php.net/rfc/fibers (read FAQ). The reason= ing was that this should be done in user space. So you should properly d= escribe in the RFC what this offers compare to user space variants (revo= lt/react/amp). There were also some concerns that it would makes things = harder to debug in internal implementation so this should be also addres= sed in the RFC. It should be noted that Fibers RFC did not preclude intr= oduction of such extensions to the core but you will likely need describ= e it in the RFC and show that there are good reasons to include.

Unfortunately, I don=E2=80=99t know much= about what happened during the adoption of Fibers, but I remember that = the situation was not ideal. I don=E2=80=99t know why that decision was = made.

For me, as a developer, the ultimate criterion is the co= de itself. If a solution makes the code better, simpler, and reduces the= number of lines, then it=E2=80=99s a good solution. If a solution force= s developers to repeatedly write the same boilerplate code, including en= tire MySQL/PostgreSQL drivers, then I can=E2=80=99t consider it a ration= al decision from a development perspective=E2=80=94though, of course, th= ere could be other reasons, such as financial constraints or lack of res= ources. Or look at Swoole=E2=80=94it has to override dozens of PHP funct= ions. Even worse, it recently started literally copying entire extension= s just for a few lines of code... =0A=0AThis does not look like a "= good solution."

AMPHP and Revolt are talented projects, but th= ey are not part of the language itself. This means that PHP extensions c= annot call user-mode code and rely on it as a standard, unlike how Rust = extensions do. Of course, from C, you can call any user-mode function, b= ut that doesn't seem like the right approach. Especially since PHP is a = high-level language, which imposes a responsibility for consistency in i= ts paradigm.

Regarding debugging=E2=80=94over the past three y= ears, there have been no debugging issues with AMPHP. Consequently, ther= e shouldn=E2=80=99t be any, since this project does not modify the Fiber= mechanism itself. It only extends it to make the tool more complete and= fully functional.

And this is precisely the main reason why I= =E2=80=99m writing these lines. As a PHP developer, I see that the langu= age is not truly complete when it comes to concurrent programming, and I= am genuinely surprised that this has not been addressed yet. How did th= is happen?

Have a nice day!

Ed.





<= /body> --1eb4f71e92cc402eadb7bbd83074baf7--