Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126408
Precedence: bulk
MIME-Version: 1.0
References: <CAMW7n8CcNuttyxhtDeG1apHFVjU_9sKAhf0RG890b82Q1AnJpw@mail.gmail.com>
In-Reply-To: <CAMW7n8CcNuttyxhtDeG1apHFVjU_9sKAhf0RG890b82Q1AnJpw@mail.gmail.com>
Date: Fri, 14 Feb 2025 14:05:15 +0100
Message-ID: <CAEKnhAFX-RnmRwgP_OoMs_fV2J_NWrfbEvUMDqMwgp_Td4JrOQ@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="0000000000000db249062e19d460"
From: bukka@php.net (Jakub Zelenka)

--0000000000000db249062e19d460
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi

On Fri, Feb 14, 2025 at 12:24=E2=80=AFPM Edmond Dantes <edmond.ht@gmail.com=
> wrote:

> Good day, everyone.
>
> I would like to request permission to create an RFC dedicated to the
> asynchronous module for PHP.
>
Someone will surely grant you karma soon. RFC makes sense.


> Although the source code development is still in progress, a significant
> part of it has already been written, and the initial tests are working
> successfully. Therefore, I could start the documentation process if you
> consider this topic relevant and interesting for the community.
> A brief overview of what this RFC will cover:
>
>    1. *True* asynchronous support for PHP core functions without
>    additional "tricks."
>    2. *Scheduler* and *Reactor* components, providing a C-API for PHP
>    extensions to enable non-blocking I/O in plugins or core code.
>    3. *User-Land API* that mirrors the C-API for PHP developers.
>    4. Basic primitives for concurrent programming, such as *Channel* and
>    *Iterator*.
>    5. *Built-in* integration with the *LibUV* library.
>
> The library is based on *Fiber*, extending and enhancing it to provide
> PHP developers with a full set of tools for concurrent applications.
>

Looks interesting. I understand that's not ready for review yet but quickly
checked the code anyway. Is there some particular reason why this is not an
extension? Think it might actually make sense to split it to two extensions
- one for the core main stuff (that could be enabled by default) and then
libuv optional part - similar to pdo for example. I haven't checked too
deeply the code though so I might be missing things. Feel free to create a
draft PR even if it's not ready. It might help to get some initial
pre-reviews... :)

Regards

Jakub

--0000000000000db249062e19d460
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_con=
tainer"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Feb 14, 2025 at 12:24=
=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"><p>Good day, everyone.</p><p>I would like to =
request permission to create an RFC dedicated to the asynchronous module fo=
r PHP.</p></div></blockquote><div>Someone will surely grant you karma soon.=
 RFC makes sense.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><p>Although the source code development is =
still in progress, a significant part of it has already been written, and t=
he initial tests are working successfully. Therefore, I could start the doc=
umentation process if you consider this topic relevant and interesting for =
the community.</p><h3>A brief overview of what this RFC will cover:</h3><ol=
><li><strong>True</strong> asynchronous support for PHP core functions with=
out additional &quot;tricks.&quot;</li><li><strong>Scheduler</strong> and <=
strong>Reactor</strong> components, providing a C-API for PHP extensions to=
 enable non-blocking I/O in plugins or core code.</li><li><strong>User-Land=
 API</strong> that mirrors the C-API for PHP developers.</li><li>Basic prim=
itives for concurrent programming, such as <strong>Channel</strong> and <st=
rong>Iterator</strong>.</li><li><strong>Built-in</strong> integration with =
the <strong>LibUV</strong> library.</li></ol><p>The library is based on <st=
rong>Fiber</strong>, extending and enhancing it to provide PHP developers w=
ith a full set of tools for concurrent applications.</p></div></blockquote>=
<div><br></div><div>Looks interesting. I understand that&#39;s not ready fo=
r review yet but quickly checked the code anyway. Is there some particular =
reason why this is not an extension? Think it might actually make sense to =
split it to two extensions - one for the core main stuff (that could be ena=
bled by default) and then libuv optional part - similar to pdo for example.=
 I haven&#39;t checked too deeply the code though so I might be missing thi=
ngs. Feel free to create a draft PR even if it&#39;s not ready. It might he=
lp to get some initial pre-reviews... :)</div><div><br></div><div>Regards</=
div><div><br></div><div>Jakub</div></div></div>

--0000000000000db249062e19d460--