rfc:fibers

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
rfc:fibers [2021/03/08 18:09] – Update intro kelunikrfc:fibers [2021/03/08 19:06] – fix typo kelunik
Line 27: Line 27:
   * Adding a ''Fiber'' class and the corresponding reflection class ''ReflectionFiber''.   * Adding a ''Fiber'' class and the corresponding reflection class ''ReflectionFiber''.
   * Adding exception classes ''FiberError'' and ''FiberExit'' to represent errors.   * Adding exception classes ''FiberError'' and ''FiberExit'' to represent errors.
 +
 +Fibers allow for transparent non-blocking I/O implementations of existing interfaces (such as PSR-7, Doctine ORM, etc.). They reduce the need for generics, because return values can use proper types directly instead of placeholder values.
  
 ==== Fibers ==== ==== Fibers ====
Line 229: Line 231:
  
 PHP 8.1 PHP 8.1
- 
-===== Future Scope ===== 
- 
-=== suspend keyword === 
- 
-''Fiber::suspend()'' could be replaced with a keyword ''suspend'' that would be similar to ''yield''. The keyword statement would accept an optional expression that would be the suspend value and return the value used to resume the fiber. 
- 
-//variable// **= suspend** //expression//**;** 
  
 ===== Proposed Voting Choices ===== ===== Proposed Voting Choices =====
Line 566: Line 560:
 It is the opinion of the authors of this RFC that it is best to provide the bare minimum in core and allow user code to implement other components as they desire. If the community moves toward a single event loop API or a need emerges for an event loop in PHP core, this can be done in a future RFC. Providing a core event loop without core functionality using it (such as streams, file access, etc.) would be misleading and confusing for users. Deferring such functionality to user frameworks and providing only a minimum API in core keeps expectations in check. It is the opinion of the authors of this RFC that it is best to provide the bare minimum in core and allow user code to implement other components as they desire. If the community moves toward a single event loop API or a need emerges for an event loop in PHP core, this can be done in a future RFC. Providing a core event loop without core functionality using it (such as streams, file access, etc.) would be misleading and confusing for users. Deferring such functionality to user frameworks and providing only a minimum API in core keeps expectations in check.
  
-This RFC does not preclude adding async/await and an event loop to core, see [[#future_scope|Future Scope]].+This RFC does not preclude adding async/await and an event loop to core.
  
 === How does this proposal differ from prior Fiber proposals? === === How does this proposal differ from prior Fiber proposals? ===
rfc/fibers.txt · Last modified: 2021/07/12 21:30 by kelunik

Page Tools