> > As long as the > transaction has not been committed or rolled back, the second > coroutine will execute queries on the same connection!
*transaction, the second coroutine will execute queries on the same transaction. Op vr 21 nov 2025 om 15:38 schreef Bart Vanhoutte < [email protected]>: > > 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 >
