Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129367
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8D0QshP8VhGOUqVnC+Uwf88TC_yy_mQdeNZW_go5YLdcw@mail.gmail.com>
 <C58ADF49-6E21-4E25-8859-2A0769829E38@php.net> <e8625214-1c6f-40b8-b24f-e592e6f92012@beccati.com>
 <CAMW7n8Dy3=QyCrG4BMwVXWAipgOr2Vyhy_jbLVTYeq2Jc5v15g@mail.gmail.com>
 <dbc31109-a43d-4afc-9f4f-62c6439328e5@rwec.co.uk> <ea59722c-2c84-4a59-a442-a8b217ff577d@gmail.com>
 <b151687a-f4bd-48cf-90e6-440f763ccd6b@rwec.co.uk> <CAMW7n8CLZ7yFhUhh89wx7L+YwQ25LA7HZoGWUFB3R76KgXko2w@mail.gmail.com>
 <CAEKnhAHRPbiU4auDuTtFL2ueNnACjmYm_ff9c3VciYE9HfeGZg@mail.gmail.com>
 <CAMW7n8D5B=XVX_Jes+LV=2fPwjQr_RBVphPi_Cxm8-_Rwpdo_Q@mail.gmail.com>
 <CADK1yX+jGtqQVYFTo5YmkenPrNcXz7Dd7RCUKWGrq+50pnKOnw@mail.gmail.com> <CAMW7n8Dogjj2JFJBNArk-BfvOHRqHKMAFReXJAhDm2UPV1TF7A@mail.gmail.com>
In-Reply-To: <CAMW7n8Dogjj2JFJBNArk-BfvOHRqHKMAFReXJAhDm2UPV1TF7A@mail.gmail.com>
Date: Fri, 21 Nov 2025 11:10:21 -0300
Message-ID: <CADK1yXKgkuKmOMB7KA9GNQMtpNw7ZgWcPEPE_Uhr_+8eReDCEA@mail.gmail.com>
Subject: Re: [PHP-DEV] [VOTE] True Async RFC 1.6
To: Edmond Dantes <edmond.ht@gmail.com>
Cc: Jakub Zelenka <bukka@php.net>, "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000002743e06441b6215"
From: deleugyn@gmail.com (Deleu)

--00000000000002743e06441b6215
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 21, 2025 at 10:45=E2=80=AFAM Edmond Dantes <edmond.ht@gmail.com=
> wrote:

>
> I have a mental habit: when I write asynchronous code, I always assume
> that any object shared between coroutines can change at any moment.
> Similarly, if you hand off memory ownership to another class or share
> memory, you have to keep in mind that there is a chance some developer
> might accidentally do something wrong.
>
> The only difference between synchronous and asynchronous code is that
> you don=E2=80=99t have a precise moment in time when the change happens. =
And
> yes, that makes debugging harder. It makes finding bugs harder. But
> it=E2=80=99s not something fundamentally new.
>

I don't know how else to describe it, but I decided to give a last attempt
here since you mentioned your mental habit: having a mental habit about
async code makes perfect sense. What I'm trying to say is that most PHP
developers don't have that mental habit and that's not a problem because
Async code in PHP doesn't come into your project out of nowhere. With
`spawn()` being native, anytime you do "composer update" your project may
start running async code without your consent and without warning you that
you should go through a mental habit that you don't even know exist because
you never had to worry about async code before in your life.

Having spawn() be an extremely easy way to start running async code is a
great feature (not a bug). But the very first thing that seems to be
missing is: I'm a dumb PHP developer that don't know and don't care about
async php and when I upgrade to PHP X.Y, how do I keep my project
always-sync without risking one of my composer packages suddenly calling
spawn() and causing bugs I have no idea how to even begin to understand?

ini settings are very frowned upon, but for the sake of a conversation, we
can think of it like that. if I do async.enabled =3D 0, then nothing change=
s
for me. Having this opt-in/opt-out control would mean that a broken website
caused by spawn() only happens if they decide to enable async and they can
start learning and developing their mental habit about how to work with
async code.

--=20
Marco Deleu

--00000000000002743e06441b6215
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Nov 21,=
 2025 at 10:45=E2=80=AFAM Edmond Dantes &lt;<a href=3D"mailto:edmond.ht@gma=
il.com">edmond.ht@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><br>
I have a mental habit: when I write asynchronous code, I always assume<br>
that any object shared between coroutines can change at any moment.<br>
Similarly, if you hand off memory ownership to another class or share<br>
memory, you have to keep in mind that there is a chance some developer<br>
might accidentally do something wrong.<br>
<br>
The only difference between synchronous and asynchronous code is that<br>
you don=E2=80=99t have a precise moment in time when the change happens. An=
d<br>
yes, that makes debugging harder. It makes finding bugs harder. But<br>
it=E2=80=99s not something fundamentally new.<br></blockquote><div><br></di=
v><div>I don&#39;t know how else to describe it, but I decided to give a la=
st attempt here since you mentioned your mental habit: having a mental habi=
t about async code makes perfect sense. What I&#39;m trying to say is that =
most PHP developers don&#39;t have that mental habit and that&#39;s not a p=
roblem because Async code in PHP doesn&#39;t come into your project out of =
nowhere. With `spawn()` being native, anytime you do &quot;composer update&=
quot; your project may start running async code without your consent and wi=
thout warning you that you should go through a mental habit that you don=
9;t even know exist because you never had to worry about async code before =
in your life.</div><div><br></div><div>Having spawn() be an extremely easy =
way to start running async code is a great feature (not a bug). But the ver=
y first thing that seems to be missing is: I&#39;m a dumb PHP developer tha=
t don&#39;t know and don&#39;t care about async php and when I upgrade to P=
HP X.Y, how do I keep my project always-sync without risking one of my comp=
oser packages suddenly calling spawn() and causing bugs I have no idea how =
to even begin to understand?</div><div><br></div><div>ini settings are very=
 frowned upon, but for the sake of a conversation, we can think of it like =
that. if I do async.enabled =3D 0, then nothing changes for me. Having this=
 opt-in/opt-out control would mean that a broken website caused by spawn() =
only happens if they decide to enable=C2=A0async and they can start learnin=
g and developing their mental habit about how to work with async code.</div=
></div><div><br></div><span class=3D"gmail_signature_prefix">-- </span><br>=
<div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><div dir=3D"ltr=
"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div =
dir=3D"ltr">Marco Deleu</div></div></div></div></div></div></div></div></di=
v>

--00000000000002743e06441b6215--