> On Mar 10, 2021, at 4:56 AM, Peter Stalman <sarke...@gmail.com> wrote: > > On Tue, Mar 9, 2021 at 6:03 PM twosee <tw...@qq.com> wrote: > > 5. Not compatible with Swoole > > In my opinion, Swoole is an important part of the PHP ecosystem. But now, > Fiber cannot work with Swoole. And based on the above reasons, Swoole will > not consider compatible fiber. > > We would expect some ZendAPI rather than Fiber extensions to provide support > for coroutine switching. > > > Hi Twosee, > > Are you saying that by adding this Fiber code to core it will prevent Swoole > from functioning? If so, that is concerning. Or are you simply saying that > Swoole doesn't like this implementation and will not use it with their own > code? > > One thing to consider when comparing the Fiber implementation is that the > vast majority of PHP applications are still run behind a web server in > short-lived requests. Unlike Swoole, Swow, and Parallel, it isn't limited to > ZTS or CLI. It might not be the ideal solution, but IMO it is a step in the > right direction for PHP to allow for better async support. > > And I think you are right that "Fiber is just an enhancement of Generator'', > but so what? The Generator addition in 5.5 opened up PHP to a hacky way of > doing async, but it worked everywhere. Fiber allows that to be much more > convenient in switching contexts deep inside a call stack. I don't think it > needs to be the end-all-be-all coroutine solution to rival Goroutines, and > I'm pretty sure it's not trying to be. > > Thanks, > Peter >
Hello, This Fiber implementation does not conflict with Swoole. Both could coexist. However, Swoole's implementation does provide some other features that this does not, so I believe Twosee was simply saying that Swoole cannot directly use this fiber implementation. My focus was to provide a minimalistic implementation in core so user space code can make other API decisions as they saw fit. Regarding some of the other concerns raised: - Switch notification: The observer notification is triggered before switching to a fiber and after suspending from a fiber. The timing here was an open question I've discussed with others and we planned to examine it later. Moving the second notification before suspending the second fiber was already being considered. As this was an internal API I felt it was not needed directly in the RFC. - Fiber is final, as is Generator. I believe it is better to compose classes rather than extend them. Of course it is always possible to remove final. - Using Fiber::resume() and Fiber::suspend() models fibers as a stack and simplifies logic of resuming/suspending fibers. Ruby fibers share this exact API, though their API uses the term yield instead of suspend. - State functions: Separate methods (i.e., isRunning, isTerminated) returning a boolean are preferable IMO to comparing integer constants to a value returned by a status method. This is really a matter of opinion than one being strictly better than the other. - Pure C coroutine: The extension code provides user space fibers. Adding functions to create fiber C-only fibers can certainly be done if the need arises. - Being marked experimental: I was hoping this would be a good compromise between allowing people to experiment with fibers and providing the ability to make minor BC breaks if the need arose. I realize this is generally not the PHP way, however this is, IMO, not entirely without precedent. JIT and FFI were not widely used before being added to PHP. Thanks for the feedback! Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
