add Fiber (sackful coroutine) support

2017-09-01 15:02 GMT+02:00 Haitao Lv i@lvht.net:

Is this your own invention, or is the name and semantics based on some
existing language or computer science theory? "Fiber" makes me think of
strings, rather than coroutines, so maybe I'm missing a key metaphor here.

Fiber is a lightweight thread. Please see
https://en.wikipedia.orghttps://github.com/amphp/artax/blob/master/lib/HttpTunneler.php/wiki/
Fiber_(computer_science)
https://en.wikipedia.org/wiki/Fiber_(computer_science)
And ruby support Fiber. Please see https://ruby-doc.org/core-2.4.
1/Fiber.html

<?php
function foo($a)
{
$b = await $a + 1;
echo $b;
}

Should "await" be "yield" here? If not, what happens if I call foo()
without being inside a Fiber?

No. A function with a yield will always return a Generator object. A fiber
with await will return any
value. You can see the await as a resumable return. The value after it
will be returned and the function
will be paused.

Similarly, if I run bar() and it runs foo(), what result will I get
outside a Fiber, since bar() has no yield, so is not itself a generator?

So the Fiber API is a little like the Generator API, but is more simple
yet powerful. So there
is no need to distinct $generator->current(), $generator->send(), and
$generator->getReturn().

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!

Nor does it seem to replace getReturn().

<?php
$f = new Fiber(function ($a) {
return 1;
});

echo $f->resume(); // will output 1

Meanwhile, how does this relate to other ways of combining generators,
such as "yield from"?

You can use Fiber to implement a more simple generator, because fiber can
be paused/resumed in its deeper
call.

<?php
function bar()
{
foreach ([5,6] as $i) {
await $i;
}
}
function foo()
{
foreach ([3,4] as $i) {
await $i;
}
bar();
}
$f = new Fiber(function ($a) {
await 1;
foo();
});

echo $f->resume(); // will output 1
echo $f->resume(); // will output 2
echo $f->resume(); // will output 3
echo $f->resume(); // will output 4
echo $f->resume(); // will output 5
echo $f->resume(); // will output 6

Fibres / Green Threads solve the problem that coroutine- / promise-based
APIs need to be viral. If any subroutine needs to await something without
blocking everything else, every parent also needs to return a promise and
be aware of it.

However, I'm not entirely sure whether they're the better solution.
Currently every yield in a coroutine in Amp is an interruption point.
Between two yields, everything is synchronous. If every function call can
now potentially await things, other things might happen (unexpectedly)
concurrently. This would need special care for some things.

The current main pain point I see for libraries like Amp is not the problem
of viral promise-APIs. It's rather the need for the boilerplate of
Amp\call(function () use ($arg1, $arg2, ...) { ... } for every coroutine
to return a promise instead of a generator, because generators are an
implementation detail, see e.g.
https://github.com/amphp/artax/blob/63f044eea7a67ac5f703232f6710846125a73fe3/lib/HttpTunneler.php#L21

A potential way around that (might be a stupid idea I just had): Allow
defining "wrappers" per file, that auto-wrap marked functions.

<?php

declare('wrapper'=Amp\coroutine);

wrapped function foo($arg1, $arg2) {
    $result = yield some_promise_returning_function();

    return $result * 2;
}

I don't see an event loop or promises being built-in soon, but something
like that could provide async with userland magic. Not the best thing,
but maybe better than preprocessing, don't know.

Regards, Niklas

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.

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.

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.

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.

Regards,

--
Rowan Collins
[IMSoP]