On Thu, Dec 17, 2020 at 5:30 PM Aaron Piotrowski <aa...@trowski.com> wrote:
> Hello everyone! > > I would like to introduce an RFC for adding full-stack fibers to PHP: > https://wiki.php.net/rfc/fibers > > Fibers are primarily used to implement green-threads or coroutines for > asynchronous I/O. Fibers are similar to threads, except fibers exist within > a single thread and require cooperative scheduling of the fibers by the > process. Since fibers do not require a full CPU context switch, they are > lightweight and more performant than multi-processing or threading for > awaiting I/O. > > An implementation as an extension is at https://github.com/amphp/ext-fiber > > Fibers are a complex feature. The RFC contains many examples and links to > code using fibers to help explain and demonstrate what is possible, however > I’m certain many more questions and concerns will arise. Looking forward to > feedback and discussion. > Hi Aaron, Thank you for the proposal. Ergonomics of async I/O in PHP certainly leave something to be desired right now, and improvements in this area are welcome. Despite your explanations in the RFC and this thread, I'm still having a hard time understanding the purpose of the FiberScheduler. My current understanding is that the FiberScheduler is a special type of fiber that cannot be explicitly scheduled by the user -- it is automatically scheduled by Fiber::suspend() and automatically un-scheduled by Fiber::resume() or Fiber::throw(). It's the fiber that runs between fibers :) Does that sound accurate? What's not clear to me is why the scheduling fiber needs to be distinguished from other fibers. If we want to stick with the general approach, why is Fiber::suspend($scheduler) not Fiber::transferTo($fiber), where $fiber would be the fiber serving as scheduler (but otherwise a normal Fiber)? I would expect that context-switching between arbitrary fibers would be both most expressive, and make for the smallest interface. The more limited alternative is to instead have Fiber::suspend() return to the parent fiber (the one that resume()d it). Here, the parent fiber effectively becomes the scheduler fiber. If I understand right, the reason why you don't want to use that approach, is that it doesn't allow you to call some AMP function from the {main} fiber, create the scheduler there and then treat {main} just like any other fiber. Is that correct? Regards, Nikita
