> 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 = 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 async and they can > start learning and developing their mental habit about how to work with 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 <[email protected]>: > > > > On Fri, Nov 21, 2025 at 10:45 AM Edmond Dantes <[email protected]> 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’t have a precise moment in time when the change happens. And >> yes, that makes debugging harder. It makes finding bugs harder. But >> it’s 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 = 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 async and they can > start learning and developing their mental habit about how to work with async > code. > > -- > Marco Deleu
