Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126416
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> <CAEKnhAHa3Xwtro7ces-x8q_YbqBqxHdTOA9xsTnW01pYjaPqrg@mail.gmail.com>
In-Reply-To: <CAEKnhAHa3Xwtro7ces-x8q_YbqBqxHdTOA9xsTnW01pYjaPqrg@mail.gmail.com>
Date: Fri, 14 Feb 2025 17:18:00 +0200
Message-ID: <CAMW7n8C9QSOth8VnYg0HTeeK6QUcU27qn7ZUNJbAsc-Y_6KreA@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000d30457062e1bae6c"
From: edmond.ht@gmail.com (Edmond Dantes)

--000000000000d30457062e1bae6c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>  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 for I/O
waiting!

> 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.
  Of course, this will need some thought.

  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 explicitl=
y
> decided not to be done in fibers RFC* - https://wiki.php.net/rfc/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 compare to user spac=
e
> 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 inclu=
de.


Unfortunately, I don=E2=80=99t know much about what happened during the ado=
ption of
Fibers, but I remember that the situation was not ideal. I don=E2=80=99t kn=
ow why
that decision was made.

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 lines,
then it=E2=80=99s a good solution. If a solution forces developers to repea=
tedly
write the same boilerplate code, including entire MySQL/PostgreSQL drivers,
then I can=E2=80=99t consider it a rational decision from a development
perspective=E2=80=94though, of course, there could be other reasons, such a=
s
financial constraints or lack of resources. Or look at Swoole=E2=80=94it ha=
s to
override dozens of PHP functions. Even worse, it recently started literally
copying entire extensions just for a few lines of code...  This does not
look like a "good solution."

AMPHP and Revolt are talented projects, but they are not part of the
language itself. This means that PHP extensions cannot 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, but that doesn't seem like the
right approach. Especially since PHP is a high-level language, which
imposes a responsibility for consistency in its paradigm.

Regarding debugging=E2=80=94over the past three years, there have been no d=
ebugging
issues with AMPHP. Consequently, there 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 language is not truly complete when it comes to
concurrent programming, and I am genuinely surprised that this has not been
addressed yet. How did this happen?

Have a nice day!

Ed.

--000000000000d30457062e1bae6c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">&gt;=C2=A0

Yeah we are actually planning better API for this supporting epoll and kque=
u which is long over due. There are other use cases for this so hopefully i=
t will get prioritised soon.<div>=C2=A0 Oh, it would be absolutely great if=
 PHP used a better abstraction for I/O waiting!</div><div><br></div><div>&g=
t; 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 oth=
er similar stuff.=C2=A0</div><div>=C2=A0 Of course, this will need some tho=
ught.</div><div><br></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"=
>=C2=A0 I have got some additional feedback from our discussion that we jus=
t had with the PHP foundation devs. <b>It was that it looks like an async/a=
wait implementation with fiber switching which is something that was explic=
itly decided not to be done in fibers RFC</b> -=C2=A0<a href=3D"https://wik=
i.php.net/rfc/fibers" target=3D"_blank">https://wiki.php.net/rfc/fibers</a>=
=C2=A0(read 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 use=
r space variants (revolt/react/amp). There were also some concerns that it =
would makes things harder to debug in internal implementation so this shoul=
d 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 ne=
ed describe it in the RFC and show that there are good reasons to include.<=
/blockquote><div><br></div><div><p>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.<=
/p><p>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 lines=
, then it=E2=80=99s a good solution. If a solution forces developers to rep=
eatedly write the same boilerplate code, including entire MySQL/PostgreSQL =
drivers, then I can=E2=80=99t consider it a rational decision from a develo=
pment perspective=E2=80=94though, of course, there could be other reasons, =
such as financial constraints or lack of resources. Or look at Swoole=E2=80=
=94it has to override dozens of PHP functions. Even worse, it recently star=
ted literally copying entire extensions just for a few lines of code...=C2=
=A0

This does not look like a &quot;good solution.&quot;

</p><p>AMPHP and Revolt are talented projects, but they are not part of the=
 language itself. This means that PHP extensions cannot call user-mode code=
 and rely on it as a standard, unlike how Rust extensions do. Of course, fr=
om C, you can call any user-mode function, but that doesn&#39;t seem like t=
he right approach. Especially since PHP is a high-level language, which imp=
oses a responsibility for consistency in its paradigm.</p><p>Regarding debu=
gging=E2=80=94over the past three years, there have been no debugging issue=
s with AMPHP. Consequently, there shouldn=E2=80=99t be any, since this proj=
ect does not modify the Fiber mechanism itself. It only extends it to make =
the tool more complete and fully functional.</p><p>And this is precisely th=
e main reason why I=E2=80=99m writing these lines. As a PHP developer, I se=
e that the language is not truly complete when it comes to concurrent progr=
amming, and I am genuinely surprised that this has not been addressed yet. =
How did this happen?</p><p>Have a nice day!</p><p>Ed.</p></div><div><br></d=
iv></div><div class=3D"gmail_quote gmail_quote_container"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
</blockquote></div></div>

--000000000000d30457062e1bae6c--