Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129371
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> <CADK1yXKgkuKmOMB7KA9GNQMtpNw7ZgWcPEPE_Uhr_+8eReDCEA@mail.gmail.com>
In-Reply-To: <CADK1yXKgkuKmOMB7KA9GNQMtpNw7ZgWcPEPE_Uhr_+8eReDCEA@mail.gmail.com>
Date: Fri, 21 Nov 2025 15:38:22 +0100
Message-ID: <CAB9bCb0FW5mvVXZWgUt6vmKoUgnFjSVHj0SBr0eLBPv+Pq1Nwg@mail.gmail.com>
Subject: Re: [PHP-DEV] [VOTE] True Async RFC 1.6
To: Deleu <deleugyn@gmail.com>, internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: bart+php@croquemonsieur.be (Bart Vanhoutte)

> ini settings are very frowned upon, but for the sake of a conversation, w=
e can think of it like that. if I do async.enabled =3D 0, then nothing chan=
ges for me. Having this opt-in/opt-out control would mean that a broken web=
site 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 wit=
h async code.


Like I said in my previous email, having a feature flag like this
would be a reasonable compromise between adoption and backwards
compatibility. Shared state is definitely a problem but there's also
less obvious things that can go wrong.

For example: database transactions are done on a per connection basis.
Sharing a single database connection for purposes other than queries
that read things is dangerous. Imagine starting a transaction in one
coroutine, doing a couple of inserts and then switching do a different
coroutine before committing the transaction. As long as the
transaction has not been committed or rolled back, the second
coroutine will execute queries on the same connection!

As for the feature flag: I would prefer something that can be enabled
on a per-project basis. I'm guessing an ini-setting could work? You
can enable it in both the configuration and in code (index.php).

As an addition, a flag in composer.json that indicates async behavior
would be a nice to have. It could warn users when they are requiring a
library that does not support async.

Best Regards,
Bart Vanhoutte


Op vr 21 nov 2025 om 15:18 schreef Deleu <deleugyn@gmail.com>:
>
>
>
> On Fri, Nov 21, 2025 at 10:45=E2=80=AFAM Edmond Dantes <edmond.ht@gmail.c=
om> 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 attemp=
t here since you mentioned your mental habit: having a mental habit about a=
sync code makes perfect sense. What I'm trying to say is that most PHP deve=
lopers 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()` b=
eing native, anytime you do "composer update" your project may start runnin=
g async code without your consent and without warning you that you should g=
o through a mental habit that you don't even know exist because you never h=
ad 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 missin=
g is: I'm a dumb PHP developer that don't know and don't care about async p=
hp and when I upgrade to PHP X.Y, how do I keep my project always-sync with=
out risking one of my composer packages suddenly calling spawn() and causin=
g bugs I have no idea how to even begin to understand?
>
> ini settings are very frowned upon, but for the sake of a conversation, w=
e can think of it like that. if I do async.enabled =3D 0, then nothing chan=
ges for me. Having this opt-in/opt-out control would mean that a broken web=
site 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 wit=
h async code.
>
> --
> Marco Deleu