2017-09-01 15:02 GMT+02:00 Haitao Lv <i...@lvht.net>:
>
> > On 1 Sep 2017, at 20:45, Rowan Collins <rowan.coll...@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/
> 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 `yield`s, 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
