>> As far as I can tell, the entire reason we are talking about this is because >> adding the event loop changes the behavior of existing code. So we cannot >> "just turn it on". >> >> I haven't seen an explanation of why this is the case, but that's how we got >> to this point. We need some way to "opt in" to turning on the event loop. > > This also seems like a very bad idea: there is no reason for the language > hide concurrency behind an INI or even worse a compilation flag. > > Existing code may not all be free from races, but the choice should be up to > the user, not the hoster or whoever provides the php distribution. > > Enabling concurrency by default will allow gradual addition of > fiber/threadsafety of codebases, as developers will know that concurrency is > a (very easy to use) option, and will hopefully want to prepare their > codebases for it, and after that happens, it will be even easier for users to > use it.
In other words, no one's forcing anyone to use async PHP: just because the language will provide a spawn/go keyword to spawn a new fiber, no one's forcing you to use it, you can keep using everything in a single thread, single fiber, no spawning. Crippling async PHP with async blocks just because some libraries aren't ready for concurrency now, means crippling the future of async php. Regards, Daniil Gentili.
