Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:126415 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 B5D3C1A00BC for ; Fri, 14 Feb 2025 15:10:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1739545645; bh=MBSH33hCtHX7Zcz9O92hRLKTCwC8WjmW96Z4kLcx7CE=; h=Date:From:To:In-Reply-To:References:Subject:From; b=CVpVfQrrmo6EdbmzGLYxPWIjcjoTQjKszBeKInRve163zxHHNip9m/GaukdyhM7BC zg8ua9ZIfdFzrEPQjIrptrcoydo27eVWh6IF5Uxh+37XUMhsbiZKZvKaMAlZT651kA u8k9gckFjQPo8Q/JZ2DKY5JJbJ94+p6wtTEVTuI9LwvyN1Xe57fnmvnFJ5xTCar5Gh 4RFro9V2lghQvgh0lVuOcksBwIh8nmQUkRLLf94acewixz2fRUdzz/nw6fUADyo31B BvqbbNzNpR/5Aap6QQq8uUmFIqyGeYsVfKUOF9aJ3q3kijFfENrY25M5SlK1C8FVz4 9x870B3LYzoYw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id DB12318004B for ; Fri, 14 Feb 2025 15:07:24 +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=-1.4 required=5.0 tests=BAYES_05,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 fout-a1-smtp.messagingengine.com (fout-a1-smtp.messagingengine.com [103.168.172.144]) (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:07:24 +0000 (UTC) Received: from phl-compute-13.internal (phl-compute-13.phl.internal [10.202.2.53]) by mailfout.phl.internal (Postfix) with ESMTP id 9FF8E138097A for ; Fri, 14 Feb 2025 10:10:06 -0500 (EST) Received: from phl-imap-09 ([10.202.2.99]) by phl-compute-13.internal (MEProxy); Fri, 14 Feb 2025 10:10:06 -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=1739545806; x=1739632206; bh=ZtRoSLutxh bXhOslorAKeRLxcE7BEgn994xoNhJYCRY=; b=oCUoGxtM+Mr/bvJnMrTOvzeRO0 ckLk1NhNnwUjUJyt5Kj5qnSyTvDVDpbrUfCOXDjl4sjlhC1jOv12tGWbGke7Um5y m1hhN0dTbArjITrmijijhP9DVi0JeclExdt2nN7ExcOmYQPPCC3a7Uk95S8Q8UJ5 zlXySBUatvDIN3B8bPwpOXuYoq1Df3NsIcXQsfEnxAW0MCn9hsJGzCAIfOmp7dnz mpCCT8ogV+2Jz/v5qRSwcMuAxAvmiZ5RwuZU1q1/rODXNfIDaSzDgK6miQBPPBmh C79eoStK41ElXfDoT/v0ARTS7NUDCazF77DHL6nvDoHjdg3ur28hICFTEIRw== 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= 1739545806; x=1739632206; bh=ZtRoSLutxhbXhOslorAKeRLxcE7BEgn994x oNhJYCRY=; b=eIpTClZMMmTY5Mmjeyihh7iu0oYevYBeExazvOK+latG3o2+DhY n5bg0PhSzfsdtLgS/oUbjvbayIz2s5HZxtWtl64toEwZOJ8Ooqcuof+guv/6MO8E qVIdL00RVaVythi7buFdyfvoKPzqL4XBIjXVK9qAuo6SXdvsjxW1a/JRXotErLtx l3L5hiuO7iyPgOUUdyac8WrTHT7ortOwPAudxg5/S8R3FPvLjagWVRDHt3Udlzex pKqdEirUnbL7ooojTvDxJWHXAGP78tuo4tPP2ak0Ixj6A49aPHQ2rW1AnwCA/r26 AKz1OsghUuAqf44zny4rrLbuv7yzGpPLyRQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdegleeljecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepofggff fhvffkjghfufgtsegrtderreertdejnecuhfhrohhmpedftfhosgcunfgrnhguvghrshdf uceorhhosgessghothhtlhgvugdrtghouggvsheqnecuggftrfgrthhtvghrnhepiedthf fhvdffhfettdfgveefgfeugeegudeukeejheeigefghfeiveelfeefueefnecuffhomhgr ihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehrohgssegsohhtthhlvggurdgtohguvghspdhnsggprhgtphht thhopedupdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehinhhtvghrnhgrlhhsse hlihhsthhsrdhphhhprdhnvght X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 2B5B5780069; Fri, 14 Feb 2025 10:10:06 -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:09:45 +0100 To: internals@lists.php.net Message-ID: <5ff33617-aa4f-4bc1-8ecf-32223773a78c@app.fastmail.com> In-Reply-To: References: Subject: Re: [PHP-DEV] PHP True Async Content-Type: multipart/alternative; boundary=b30547bedd9840f9a801ae1a098b9506 From: rob@bottled.codes ("Rob Landers") --b30547bedd9840f9a801ae1a098b9506 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 14, 2025, at 15:16, Edmond Dantes wrote: > Hello, *Jakub.* > (It seems that simply clicking "Reply" does not work for the conferenc= e) > ** > *> *I understand that's not ready for review yet but quickly > You could say that the code is in a state of "architectural stabilit= y," so it can be reviewed and criticized. (Unfortunately, only the Windo= ws build is currently working.)=20 > In the near future, I plan to start documenting the C-API, where I wil= l describe the implementation details in depth, but feel free to ask any= questions about this component. =20 >=20 > Link: https://github.com/EdmondDantes/php-src/tree/async/async >=20 > > Is there some particular reason why this is not an extension? >=20 > There are two reasons: one objective and one relatively subjective. >=20 > _The objective reason_ is that there are critical changes that simply = cannot be done in an extension. This includes modifying the logic of fun= ctions like `php_select`/`php_poll2`. >=20 > The relatively subjective reason is that it was extremely difficult fo= r me to design the architecture within the constraints of an extension b= ecause, at the start of the project, I had no clear idea of how to imple= ment it at all... :) >=20 > Theoretically, the project could be split into two separate components= : core modifications and an external EXT component. Now that I have a wo= rking codebase, it would be much easier to do. >=20 > And yes, you've raised a very important point. In CGI applications, th= is component is likely to be of little use (although in some cases, it m= ight still be beneficial even for CGI). So keeping the entire codebase i= n the PHP core is not a good approach. I=E2=80=99m sure many people will= point that out :) And I agree. But for now, the component is built usin= g configuration options in `buildconf`, which is sufficient as a startin= g point. >=20 > If your question is whether core modifications could be avoided, the a= nswer is no. The whole purpose of this project is to make PHP more suita= ble for LongRunning Apps. >=20 > > and then libuv optional part - similar to pdo for example. >=20 > That's exactly how it has already been implemented! *LibUV* is not tig= htly coupled to the code. Moreover, it can be replaced on the fly with a= ny other implementation=E2=80=94for example, Swoole can serve as the bac= kend for the reactor, or RUST TOKIO, or perhaps someone might want to cr= eate something else. >=20 >=20 > In essence, the Reactor is just an API and can be defined via an exten= sion. > LibUV is included as an embedded piece of code that can be compiled di= rectly with the project if a specific flag is set, but of course, it can= also be provided as an extension. (The reason why LibUV is provided as = the "default solution" is that it is written in C and is cross-platform.= This is important for PHP. ) >=20 > I plan to do the same with the Scheduler component in the future.=20 >=20 > Thanks for questions! >=20 >=20 > =D0=BF=D1=82, 14 =D1=84=D0=B5=D0=B2=D1=80. 2025=E2=80=AF=D0=B3. =D0=B2= 15:05, Jakub Zelenka : >=20 >>>=20 Hello, I'm actually curious why you chose libuv? This may no longer be true tod= ay, but I remember distinctly not choosing libuv on a previous project d= ue to some compatibility concerns. It was a php project + custom extensi= ons, and the issue was directly related to other official/pecl extension= s. We didn't have this issue with libev, fwiw. It was a long time ago th= ough, so maybe the issues no longer exist, and I don't remember the deta= ils. =E2=80=94 Rob --b30547bedd9840f9a801ae1a098b9506 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 14,= 2025, at 15:16, Edmond Dantes wrote:
Hello, Jakub.
(It seems that simply c= licking "Reply" does not work for the conference)
=
> I u= nderstand that's not ready for review yet but quickly
  You could say that the code is in a state of "architectural st= ability," so it can be reviewed and criticized. (Unfortunately, only the= Windows build is currently working.) 
In the near fu= ture, I plan to start documenting the C-API, where I will describe the i= mplementation details in depth, but feel free to ask any questions about= this component.  


> Is there some particular reason why this is not a= n extension?

There are two reason= s: one objective and one relatively subjective.

The objecti= ve reason is that there are critical changes that simply cannot= be done in an extension. This includes modifying the logic of functions= like php_select/php_poll2.

The= relatively subjective reason is that it was extremely difficult for me = to design the architecture within the constraints of an extension becaus= e, at the start of the project, I had no clear idea of how to implement = it at all... :)

Theoretically, the project could be split into= two separate components: core modifications and an external EXT compone= nt. Now that I have a working codebase, it would be much easier to do.

And yes, you've raised a very important point. In CGI applicati= ons, this component is likely to be of little use (although in some case= s, it might still be beneficial even for CGI). So keeping the entire cod= ebase in the PHP core is not a good approach. I=E2=80=99m sure many peop= le will point that out :) And I agree. But for now, the component is bui= lt using configuration options in buildconf, which is = sufficient as a starting point.

If your question is whether co= re modifications could be avoided, the answer is no. The whole purpose o= f this project is to make PHP more suitable for LongRunning Apps.

> and= then libuv optional part - similar to pdo for example.

That's exactly how it has already been implemented! LibUV&n= bsp;is not tightly coupled to the code. Moreover, it can be replaced on = the fly with any other implementation=E2=80=94for example, Swoole can se= rve as the backend for the reactor, or RUST TOKIO, or perhaps someone mi= ght want to create something else.

In essence, the Re= actor is just an API and can be defined via an extension.
= LibUV is included as an embedded piece of code that can be compiled dire= ctly with the project if a specific flag is set, but of course, it can a= lso be provided as an extension. (The reason why LibUV is provided as th= e "default solution" is that it is written in C and is cross-platform. T= his is important for PHP.  )

I plan to do the sa= me with the Scheduler component in the future. 

Thanks fo= r questions!


=D0=BF=D1=82, 14 =D1=84=D0= =B5=D0=B2=D1=80. 2025=E2=80=AF=D0=B3. =D0=B2 15:05, Jakub Zelenka <bukka@php.net>:<= br>



Hello,

I'm actually c= urious why you chose libuv? This may no longer be true today, but I reme= mber distinctly not choosing libuv on a previous project due to some com= patibility concerns. It was a php project + custom extensions, and the i= ssue was directly related to other official/pecl extensions. We didn't h= ave this issue with libev, fwiw. It was a long time ago though, so maybe= the issues no longer exist, and I don't remember the details.

=E2=80=94 Rob
--b30547bedd9840f9a801ae1a098b9506--