Re: add Fiber (sackful coroutine) support

2017-09-01 15:02 GMT+02:00 Haitao Lv <i@lvht.net>: > > > On 1 Sep 2017, at 20:45, Rowan Collins <rowan.collins@gmail.com> wrote: > > > > 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/�����I��`Ծ� > K� > 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 <?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