Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126576
Precedence: bulk
MIME-Version: 1.0
References: <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
In-Reply-To: <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
Date: Wed, 5 Mar 2025 11:58:05 +0100
Message-ID: <CAEKnhAHv_3bR+Fnmg=mGXuDJhpmAjTMwj0VhAt8TOcjiD+YJzw@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="000000000000376877062f9644c6"
From: bukka@php.net (Jakub Zelenka)

--000000000000376877062f9644c6
Content-Type: text/plain; charset="UTF-8"

Hi,

> https://wiki.php.net/rfc/true_async
>
> I believe this version is not perfect and requires analysis. And I
> strongly believe that things like this shouldn't be developed in isolation.
> So, if you think any important (or even minor) aspects have been
> overlooked, please bring them to attention.
>

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. It means it should probably disallow global
(e.g. global $var;) variables or at least make them context specific as
well as disallowing object sharing. I think PHP users should not deal with
synchronization primitives. Basically what I want to say is that
multithreading should not be just something mentioned in the future scope
but the whole design should be done in a way that will make sure everything
will work fine for users. Ideally also having some simplified
implementation that will verify it.

I also agree that the scope is currently too big. It should be reduced to
the absolute minimum and just show what's possible. It's great to have a
proof of concept for that but the initial proposal should be mainly about
the design and introducing the core components.

Regards,

Jakub

--000000000000376877062f9644c6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div class=3D"gmail_quote gmail_quote_contai=
ner"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><p>=
<a href=3D"https://wiki.php.net/rfc/true_async" target=3D"_blank">https://w=
iki.php.net/rfc/true_async</a></p><p>I believe this version is not perfect =
and requires analysis. And I strongly believe that things like this shouldn=
&#39;t be developed in isolation. So, if you think any important (or even m=
inor) aspects have been overlooked, please bring them to attention.</p></di=
v></blockquote><div><br></div><div>I thought about this quite a bit and I t=
hink we should first try to clarify the primary design that we want to go f=
or. 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&=
#39;t be initially supported), then we should take it into the account from=
 the beginning and add restrictions to prevent race conditions. It means it=
 should probably disallow global (e.g. global $var;) variables or at least =
make them context specific as well as disallowing object sharing. I think P=
HP users should not deal with synchronization primitives. Basically what I =
want to say is that multithreading should not be just something mentioned i=
n the future scope but the whole design should be done in a way that will m=
ake sure everything will work fine for users. Ideally also having some simp=
lified implementation that will verify it.</div><div><br></div><div>I also =
agree that the scope is currently too big. It should be reduced to the abso=
lute minimum and just show what&#39;s possible. It&#39;s great to have a pr=
oof of concept for that but the initial proposal should be mainly about the=
 design and introducing the core components.</div><div><br></div><div>Regar=
ds,</div><div><br></div><div>Jakub</div></div></div>

--000000000000376877062f9644c6--