> On 2 Sep 2017, at 20:19, Rowan Collins <[email protected]> wrote:
>
> On 1 September 2017 14:02:29 BST, Haitao Lv <[email protected]> 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
