> From the standpoint of PHP language user, I have a completely different view
> on Fibers vs. Corotines.
That’s sad.
> They look very similar from the outside
Coroutines and Fibers have completely different behavior. I hope
you’re not comparing them just by appearance?
> I really belief we should avoid fragmentation and enhance/adjust Fibers to
> meet the memory and performance requirements of a Coroutine.
But the problem has already happened, and it’s not directly related to this RFC.
Of course, there’s a possibility to bridge the two worlds by calling
PHP functions from C, but as I’ve said before: just because something
can be done doesn’t mean it should be done.
> If the provided awaitable is itself some infinitely blocking Coroutine (e.g.
> while (true) {}),
If you have a coroutine with an infinite loop, it means other
coroutines will never get control.
(more about it by searching for the keyword: “concurrency")
The RFC contains an example that isn’t very elegant from a semantic
point of view, but is completely correct in terms of logic:
```php
// Await task 1, but no longer than 5 seconds.
await($task1, spawn(sleep(...), 5));
```
And here’s another piece of code (Async\Signal is not present in the
RFC, but it’s entirely possible.):
```php
// Await task 1 until a signal occurs.
await($task1, new Async\Signal(SIG_TERM));
```
> In addition, what happens if a Coroutine is suspended and is restarted again.
The Await function waits for the coroutine to complete.
The suspended state does not affect the waiting process.
The wait is interrupted for two reasons: an unhandled exception or the
coroutine’s completion.
All of this is described in the RFC: https://wiki.php.net/rfc/true_async#await
---
Ed
