Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126414
Precedence: bulk
MIME-Version: 1.0
References: <CAMW7n8CcNuttyxhtDeG1apHFVjU_9sKAhf0RG890b82Q1AnJpw@mail.gmail.com>
 <CAEKnhAFX-RnmRwgP_OoMs_fV2J_NWrfbEvUMDqMwgp_Td4JrOQ@mail.gmail.com>
 <CAMW7n8AC_VAg0eOZFBorma2jFX=5eS0TCSOP2sY67Dz6BiQyjQ@mail.gmail.com> <CAMW7n8D5kEB88qJiV8dx5fP9KGbaUa6Xc9znjqYcNOjG4oiXBQ@mail.gmail.com>
In-Reply-To: <CAMW7n8D5kEB88qJiV8dx5fP9KGbaUa6Xc9znjqYcNOjG4oiXBQ@mail.gmail.com>
Date: Fri, 14 Feb 2025 15:47:02 +0100
Message-ID: <CAEKnhAHa3Xwtro7ces-x8q_YbqBqxHdTOA9xsTnW01pYjaPqrg@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async
To: Edmond Dantes <edmond.ht@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000000dae3c062e1b405d"
From: bukka@php.net (Jakub Zelenka)

--0000000000000dae3c062e1b405d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Fri, Feb 14, 2025 at 3:21=E2=80=AFPM Edmond Dantes <edmond.ht@gmail.com>=
 wrote:

> Hello, *Jakub.*
> (It seems that simply clicking "Reply" does not work for the conference)
>
> *> *I understand that's not ready for review yet but quickly
>   You could say that the code is in a state of "architectural stability,"
> so it can be reviewed and criticized. (Unfortunately, only the Windows
> build is currently working.)
> In the near future, I plan to start documenting the C-API, where I will
> describe the implementation details in depth, but feel free to ask any
> questions about this component.
>
> Link: https://github.com/EdmondDantes/php-src/tree/async/async
>
> > Is there some particular reason why this is not an extension?
>
> There are two reasons: one objective and one relatively subjective.
>
> *The objective 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.
>

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.

> The relatively subjective reason is that it was extremely difficult for m=
e
> to design the architecture within the constraints of an extension because=
,
> at the start of the project, I had no clear idea of how to implement it a=
t
> all... :)
>
> Theoretically, the project could be split into two separate components:
> core modifications and an external EXT component. Now that I have a worki=
ng
> codebase, it would be much easier to do.
>

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.

> And yes, you've raised a very important point. In CGI applications, this
> component is likely to be of little use (although in some cases, it might
> still be beneficial even for CGI). So keeping the entire codebase in 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 using configuration
> options in buildconf, which is sufficient as a starting point.
>
> If your question is whether core modifications could be avoided, the
> answer is no. The whole purpose of 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* 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 serve as the bac=
kend for
> the reactor, or RUST TOKIO, or perhaps someone might want to create
> something else.
>
> In essence, the Reactor is just an API and can be defined via an extensio=
n.
> LibUV is included as an embedded piece of code that can be compiled
> directly with the project if a specific flag is set, but of course, it ca=
n
> also 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. This
> is important for PHP.  )
>
Yes and that's why it would better to the ext directory.

> I plan to do the same with the Scheduler component in the future.
>
> Thanks for questions!
>
I have got some additional feedback from our discussion that we just had
with the PHP foundation devs. It was that it looks like an async/await
implementation with fiber switching which is something that was explicitly
decided not to be done in fibers RFC - https://wiki.php.net/rfc/fibers (rea=
d
FAQ). The reasoning was that this should be done in user space. So you
should properly describe in the RFC what this offers compare to user space
variants (revolt/react/amp). There were also some concerns that it would
makes things harder to debug in internal implementation so this should be
also addressed in the RFC. It should be noted that Fibers RFC did not
preclude introduction of such extensions to the core but you will likely
need describe it in the RFC and show that there are good reasons to include=
.

Hope it helps!

Kind regards,

Jakub

--0000000000000dae3c062e1b405d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><br><div class=3D"gmail_quote gmail_quote_co=
ntainer"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Feb 14, 2025 at 3:21=
=E2=80=AFPM Edmond Dantes &lt;<a href=3D"mailto:edmond.ht@gmail.com">edmond=
.ht@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div>Hello,=
=C2=A0<span style=3D"color:rgb(31,31,31);font-size:0.875rem;font-family:&qu=
ot;Google Sans&quot;,Roboto,RobotoDraft,Helvetica,Arial,sans-serif"><b>Jaku=
b.</b><br>(</span>It seems that simply clicking &quot;Reply&quot; does not =
work for the conference<span style=3D"color:rgb(31,31,31);font-family:&quot=
;Google Sans&quot;,Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:=
0.875rem">)</span></div><span style=3D"color:rgb(80,0,80)"><div><span style=
=3D"color:rgb(31,31,31);font-size:0.875rem;font-weight:bold;font-family:&qu=
ot;Google Sans&quot;,Roboto,RobotoDraft,Helvetica,Arial,sans-serif"><br></s=
pan></div><div><font color=3D"#1f1f1f" face=3D"Google Sans, Roboto, RobotoD=
raft, Helvetica, Arial, sans-serif"><span style=3D"font-size:14px"><b>&gt;=
=C2=A0</b></span></font>I understand that&#39;s not ready for review yet bu=
t quickly</div></span><div>=C2=A0 You could say that the code is in a state=
 of &quot;architectural stability,&quot; so it can be reviewed and criticiz=
ed. (Unfortunately, only the Windows build is currently working.)=C2=A0</di=
v><div>In the near future, I plan to start documenting the C-API, where I w=
ill describe the implementation details in depth, but feel free to ask any =
questions about this component.=C2=A0=C2=A0</div><div><br></div>Link:=C2=A0=
<a href=3D"https://github.com/EdmondDantes/php-src/tree/async/async" target=
=3D"_blank">https://github.com/EdmondDantes/php-src/tree/async/async</a><sp=
an style=3D"color:rgb(80,0,80)"><div><br></div><div>&gt; Is there some part=
icular reason why this is not an extension?</div><div><br></div></span><div=
><p>There are two reasons: one objective and one relatively subjective.</p>=
<p><u>The objective reason</u>=C2=A0is that there are critical changes that=
 simply cannot be done in an extension. This includes modifying the logic o=
f functions like=C2=A0<code>php_select</code>/<code>php_poll2</code>.</p></=
div></div></div></div></blockquote><div><br></div><div>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 prioritis=
ed soon.</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D=
"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div><p>The relatively subjective r=
eason is that it was extremely difficult for me to design the architecture =
within the constraints of an extension because, at the start of the project=
, I had no clear idea of how to implement it at all... :)</p><p>Theoretical=
ly, the project could be split into two separate components: core modificat=
ions and an external EXT component. Now that I have a working codebase, it =
would be much easier to do.</p></div></div></div></div></blockquote><div><b=
r></div><div>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 strea=
ms and other similar stuff.=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div><p>An=
d yes, you&#39;ve raised a very important point. In CGI applications, this =
component is likely to be of little use (although in some cases, it might s=
till be beneficial even for CGI). So keeping the entire codebase in 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 using configuration=
 options in=C2=A0<code>buildconf</code>, which is sufficient as a starting =
point.</p><p>If your question is whether core modifications could be avoide=
d, the answer is no. The whole purpose of this project is to make PHP more =
suitable for LongRunning Apps.</p><span style=3D"color:rgb(80,0,80)"><p>&gt=
; and then libuv optional part - similar to pdo for example.</p></span><p>T=
hat&#39;s exactly how it has already been implemented!=C2=A0<b>LibUV</b>=C2=
=A0is not tightly coupled to the code. Moreover, it can be replaced on the =
fly with any other implementation=E2=80=94for example, Swoole can serve as =
the backend for the reactor, or RUST TOKIO, or perhaps someone might want t=
o create something else.</p><p>In essence, the Reactor is just an API and c=
an be defined via an extension.<br>LibUV is included as an embedded piece o=
f code that can be compiled directly with the project if a specific flag is=
 set, but of course, it can also be provided as an extension. (The reason w=
hy LibUV is provided as the &quot;default solution&quot; is that it is writ=
ten in C and is cross-platform. This is important for PHP.=C2=A0 )</p></div=
></div></div></div></blockquote><div>Yes and that&#39;s why it would better=
 to the ext directory.</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div><p>I plan to do =
the same with the Scheduler component in the future.=C2=A0</p><p>Thanks for=
 questions!</p></div></div></div></div></blockquote><div>I have got some ad=
ditional feedback from our discussion that we just had with the PHP foundat=
ion devs. It was that it looks like an async/await implementation with fibe=
r switching which is something that was explicitly decided not to be done i=
n fibers RFC -=C2=A0<a href=3D"https://wiki.php.net/rfc/fibers" target=3D"_=
blank">https://wiki.php.net/rfc/fibers</a>=C2=A0(read FAQ). The reasoning w=
as that this should be done in user space. So you should properly describe =
in the RFC what this offers compare to user space variants (revolt/react/am=
p). There were also some concerns that it would makes things harder to debu=
g in internal implementation so this should be also addressed in the RFC. I=
t should be noted that Fibers RFC did not preclude introduction of such ext=
ensions to the core but you will likely need describe it in the RFC and sho=
w that there are good reasons to include.</div><div><br></div><div>Hope it =
helps!</div><div><br></div><div>Kind regards,</div><div><br></div><div>Jaku=
b</div></div></div>

--0000000000000dae3c062e1b405d--