> On Feb 8, 2018, at 12:18, Aaron Piotrowski <aa...@trowski.com> wrote: > >> >> On Feb 7, 2018, at 7:05 PM, Haitao Lv <i...@lvht.net> wrote: >> >> Hi internals, >> >> I propose to introduce the Fiber feature AGAIN. >> >> The main purpose of the RFC is to introducing a lightweight stackful >> coroutine support for PHP and make it possible to write non-blocking code in >> the blocking style. >> >> In this RFC, no new keyword is needed. So it will not break the PHP 7.3 >> release. >> >> Please see the RFC https://wiki.php.net/rfc/fiber >> >> Dmitry and I are working on the implementation at >> https://github.com/fiberphp/fiber-ext >> And a series of usage demo can be found at >> https://github.com/fiberphp/fiber-demo >> >> Please offer you comments. >> >> Thank you. >> >> --- >> Haitao Lv >> > > > Hi Haitao, > > I'm very excited to see this sort of feature coming to PHP. > > A couple of questions and thoughts: > > - How do you determine when a fiber has returned? Looking at the source, it > appears Fiber::status() must be used, comparing against constants. Separate > methods similar to Generator would be better IMO. e.g.: Fiber::alive(), > Fiber::suspended(), Fiber::running()
Offering methods like Fiber::alive, Fiber::running makes no difference to check the Fiber::status() return value. This is just a style issue. And as a language feature, Fiber only offer the essential API and let other works to the user land. > - What about throwing exceptions into a fiber? Currently does not support throw exception into the fiber. User land code could check the value of Fiber::yield and throw exception themselves. The Ruby's Fiber and Lua's coroutine also does not support such api as well. > > - Using Fiber::resume() to initialize the fiber and resume feels awkward. > Separate methods again would be better here, perhaps Fiber::init(...$args) > and Fiber::resume($send). All Fiber created with a suspended status. So make resume to do both the init and resume do make sense. Please see Ruby Fiber API https://ruby-doc.org/core-2.2.0/Fiber.html. > > - What happens if the sub1() function in the RFC is invoked outside of a > fiber? You will get a Fatal Error like Fatal error: Uncaught Error: Cannot call Fiber::yield out of Fiber > - I think a keyword here would be beneficial, even if it has a minor BC > impact. Fibers could then be written like generators. `await` or `emit` as a > keyword perhaps? This would be a less verbose API, feel less magical (a > static method call that actually pauses execution feels out of place), and > would allow Fibers to be returned from methods, named functions, etc with > less boilerplate. Wishing this to be accepted by the community in the PHP 7.3, so no keyword is accepted. And if the community cannot accept, the Fiber can be still distributed as a standalone extension. So we cannot depend on a new keyword. > Thanks to you and Dmitry for working on this! > > Aaron Piotrowski > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
