Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126581
Precedence: bulk
MIME-Version: 1.0
References: <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
 <CAEKnhAHv_3bR+Fnmg=mGXuDJhpmAjTMwj0VhAt8TOcjiD+YJzw@mail.gmail.com> <CAMW7n8DHFb6innyn6VigDtQGb9EYu9-H_v5m_XGJWHEQG+q2OA@mail.gmail.com>
In-Reply-To: <CAMW7n8DHFb6innyn6VigDtQGb9EYu9-H_v5m_XGJWHEQG+q2OA@mail.gmail.com>
Date: Wed, 5 Mar 2025 17:55:23 +0100
Message-ID: <CAEKnhAGc-hOPkEfiBouA+XD0A1oEjt1jtg_u=uZohbbDYg=7Pg@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC
To: Edmond Dantes <edmond.ht@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000007e3aa062f9b421e"
From: bukka@php.net (Jakub Zelenka)

--00000000000007e3aa062f9b421e
Content-Type: text/plain; charset="UTF-8"

Hi,

>
> > I thought about this quite a bit and I think we should first try to
> clarify the primary design that we want to go for.
> > What I mean is whether we would like to ever support a true concurrency
> (threads) in it.
> > If we think it would be worth it (even thought it wouldn't be initially
> supported), then we should take it into the account from the beginning and
> add restrictions to prevent race conditions.
> >
>
> If you mean multitasking, i.e., executing coroutines in different OS
> threads, then this feature is far beyond the scope of this RFC and would
> require significant changes to the PHP core (Memory manager first).
>

You might want to look to parallel extension as it's already dealing with
that and mostly works - of course combination with coroutines will
certainly complicate it but the point is that memory is not shared.


> And even if we imagine that such changes are made, eliminating data races
> without breaking the language is, to put it mildly, a questionable task
> from the current perspective.
>

That's exactly what I meant is to make sure that there won't be any data
races - it means use only channel communication (more below).


>
> Although this RFC raises the question of whether a concurrent version
> without multitasking is worth implementing at all, my opinion is positive.
> For PHP, this could be sufficient as a language primarily used in the
> context of asynchronous I/O, whereas a multitasking version may never
> happen.
>
>
I didn't really mean to introduce it as part of this RFC. What I meant is
to design the API so there is still possibility to add it in the future
without risking various race condition in the code. It means primarily to
put certain restrictions that will prevent it like limited access to global
and passing anything by reference (including objects) to the running tasks.

Regards

Jakub

--00000000000007e3aa062f9b421e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><div>Hi,<=
/div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div><span style=3D"color:rgb(31,31,31);font-size:0.875rem;font=
-weight:bold;font-family:&quot;Google Sans&quot;,Roboto,RobotoDraft,Helveti=
ca,Arial,sans-serif"></span></div><div><font color=3D"#1f1f1f" face=3D"Goog=
le Sans, Roboto, RobotoDraft, Helvetica, Arial, sans-serif"><span style=3D"=
font-size:14px">&gt;<br>&gt;=C2=A0</span></font>I thought about this quite =
a bit and I think we should first try to clarify the primary design that we=
 want to go for. <br>&gt; What I mean is whether we would like to ever supp=
ort a true concurrency (threads) in it. <br>&gt; If we think it would be wo=
rth it (even thought it wouldn&#39;t be initially supported), then we shoul=
d take it into the account from the beginning and add restrictions to preve=
nt race conditions.</div><div><font color=3D"#1f1f1f" face=3D"Google Sans, =
Roboto, RobotoDraft, Helvetica, Arial, sans-serif"><span style=3D"font-size=
:14px">&gt;<br><br></span></font>If you mean multitasking, i.e., executing =
coroutines in different OS threads, then this feature is far beyond the sco=
pe of this RFC and would require significant changes to the PHP core (Memor=
y manager first).</div></div></blockquote><div><br></div><div>You might wan=
t to look to parallel extension as it&#39;s already dealing with that and m=
ostly works - of course combination with coroutines will certainly complica=
te it but the point is that memory is not shared.</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>And ev=
en if we imagine that such changes are made, eliminating data races without=
 breaking the language is, to put it mildly, a questionable task from the c=
urrent perspective.=C2=A0</div></div></blockquote><div><br></div><div>That&=
#39;s exactly what I meant is to make sure that there won&#39;t be any data=
 races - it means use only channel communication (more below).</div><div>=
=C2=A0</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"l=
tr"><div><br></div><div>Although this RFC raises the question of whether a =
concurrent version without multitasking is worth implementing at all, my op=
inion is positive. For PHP, this could be sufficient as a language primaril=
y used in the context of asynchronous I/O, whereas a multitasking version m=
ay never happen.=C2=A0</div><div><br></div></div></blockquote><div><br></di=
v><div>I didn&#39;t really mean to introduce it as part of this RFC. What I=
 meant is to design the API so there is still possibility to add it in the =
future without risking various race condition in the code. It means primari=
ly to put certain restrictions that will prevent it like limited access to =
global and passing anything by reference (including objects) to the running=
 tasks.</div><div><br></div><div>Regards</div><div><br></div><div>Jakub</di=
v><div>=C2=A0</div></div></div>

--00000000000007e3aa062f9b421e--