> > As a heavy use of both amphp and go, cancellations (contexts in go) are > absolutely needed, as a fiber may spawn further background fibers in order > to execute some operation, just cancelling that specific fiber will not > cancel the spawned fibers, unless a bunch of boilerplate try-catch blocks > are added to propagate CancellationExceptions.
I didn't mean that Cancellation isn't needed at all. I meant that canceling a Fiber is sufficient in most scenarios and leads to clean, understandable code. Other languages have child coroutines (Swoole supports them too), but I'm not sure if that's the right approach. I like context.WithCancel from Go, but it can essentially be implemented directly in PHP land since all the necessary tools are available. A nicer API should use only explicit cancellation objects, as this pattern > of preemptive implicit cancellations The exception mechanism is the standard way to alter the execution flow in PHP. If a programmer writes code with lock and unlock outside of a try-finally block but calls functions between these methods, they are potentially creating a bad solution—at the very least because someone else might later introduce an exception in one of those functions. This is a classic case for languages with exceptions. So far, I haven't found a better way to ensure the logical consistency and integrity of the execution flow. Maybe someone has a suggestion? > The main reason given in the RFC > > The main reason is that PHP has been around for many years and didn’t just appear yesterday. If you have an idea on how to start the Scheduler implicitly, let's implement it. So far, I have a few ideas: 1. Using an option in php.ini (downside: if PHP is used for multiple projects). 2. Using a CLI option – so far, I like this the most. A thing I would love to see, on the other hand, is for Context to become a “provider” It's hard for me to evaluate this idea. Intuitively, it doesn't seem ideal. In general, I'm not very fond of $_GET/$_POST. But on the other hand, why not? This needs some consideration. allow to very easily to turn i.e. php-fpm into a fully asynchronous application server, > where each request is started in the same thread (or in N threads in an M-N > M>N > execution model) but its global state is entirely isolated between fibers. > > I haven’t thought about this possibility. But wouldn’t this break the FCGI contract? Thanks! Ed. >
