Re: add Fiber (sackful coroutine) support

the best corotine . must be golang go and chan. very easy to use. non blocking. On Sat, Sep 9, 2017 at 2:28 PM +0800, "Haitao Lv" <i@lvht.net> wrote: > On 2 Sep 2017, at 20:19, Rowan Collins wrote: > > On 1 September 2017 14:02:29 BST, Haitao Lv wrote: >> >> Fiber is a lightweight thread. Please see >> https://en.wikipedia.org/wiki/Fiber_(computer_science) >> And ruby support Fiber. Please see >> https://ruby-doc.org/core-2.4.1/Fiber.html > > Ah, thanks, that makes more sense now. > > I note that the examples there all implement it not as a keyword, but as a library function, > which maybe makes more sense: whereas "yield" turns a function declaration into a > generator declaration, "Fiber\yield", as we might call it, is just a function call which > can happen anywhere and manipulates some global state. As the Zend Engine does not offer API to pause execution, I cannot implement the await without introducing a new keyword (just like yield). > The choice of "await" also feels odd: you're not awaiting the thing on the > right-hand side of the keyword, you're sending it somewhere and awaiting something else. await is chosen because we cannot reuse the yield keyword. Maybe we can choose a more proper keyword. >> You can see the await as a resumable return. The value after it >> will be returned and the function >> will be paused. > > Again, this explanation doesn't make sense if you can call foo() without any Fiber code. > If there isn't an active Fiber to pause, the "await" line can't > "return" anything; it will presumably throw an error of some sort. > > function foo($x) { > $y = Fiber\yield($x); > return $x + $y; > } > echo foo(1); > > The 1 isn't "returned" to the echo, it's passed off to a global function > for further processing. This makes much more sense to me than implying that foo() is no longer a > normal function. await is not yield. It need a separate vm stack to work. So call the foo function without a Fiber will throw a runtime error exception. > >>> Your ->resume() doesn't seem to do anything a normal generator can't, >> except that the yield is nested deeper. >> >> The await is a nested deeper yield! > > Yes, I understand that, but that seems to be completely unrelated to the API design of having > resume() act as start, continue, and final result all rolled into one. As I say, I didn't > entirely follow the reasoning for allowing return in generators, but if Fibers are used for the same > purpose, I would expect the same concerns to arise. > > However, I think the comparison to generators may be more distracting than useful, as they seem > to be very different solutions to the same or related problems. If fiber were implemented, the generator would be a special fiber. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php