rfc:fibers
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
rfc:fibers [2021/03/08 17:08] – Update stubs trowski | rfc:fibers [2021/07/12 21:30] (current) – kelunik | ||
---|---|---|---|
Line 3: | Line 3: | ||
* Date: 2021-03-08 | * Date: 2021-03-08 | ||
* Authors: Aaron Piotrowski < | * Authors: Aaron Piotrowski < | ||
- | * Status: | + | * Status: |
* First Published at: http:// | * First Published at: http:// | ||
===== Introduction ===== | ===== Introduction ===== | ||
- | For most of PHP’s history, people have written PHP code only as synchronous code. They have code that runs synchronously and in turn, only calls functions | + | For most of PHP’s history, people have written PHP code only as synchronous code. Execution of functions |
- | More recently, there have been multiple projects that have allowed people to write asynchronous PHP code. Asynchronous functions accept a callback or return a placeholder for a future value (such as a promise) to run code at a future time once the result is available. Execution continues without waiting for a result. Examples of these projects are [[https:// | + | More recently, there have been multiple projects that have allowed people to write asynchronous PHP code to allow for concurrent I/O operations. Asynchronous functions accept a callback or return a placeholder for a future value (such as a promise) to run code at a future time once the result is available. Execution continues without waiting for a result. Examples of these projects are [[https:// |
The problem this RFC seeks to address is a difficult one to explain, but can be referred to as the [[https:// | The problem this RFC seeks to address is a difficult one to explain, but can be referred to as the [[https:// | ||
Line 18: | Line 18: | ||
* Asynchronous functions change the way the function must be called. | * Asynchronous functions change the way the function must be called. | ||
* Synchronous functions may not call an asynchronous function (though asynchronous functions may call synchronous functions). | * Synchronous functions may not call an asynchronous function (though asynchronous functions may call synchronous functions). | ||
- | * Calling an asynchronous function requires the entire | + | * Calling an asynchronous function requires the entire |
- | For people who are familiar with using promises and await/yield to achieve writing asynchronous code, the problem can be expressed as: “Once one function returns a promise somewhere in your call stack, the entire call stack needs to return a promise because the result of the call cannot be known until the promise is resolved.” | + | For people who are familiar with using promises and/or await/yield to achieve writing asynchronous code, the problem can be expressed as: “Once one function returns a promise somewhere in your call stack, the entire call stack needs to return a promise because the result of the call cannot be known until the promise is resolved.” |
This RFC seeks to eliminate the distinction between synchronous and asynchronous functions by allowing functions to be interruptible without polluting the entire call stack. This would be achieved by: | This RFC seeks to eliminate the distinction between synchronous and asynchronous functions by allowing functions to be interruptible without polluting the entire call stack. This would be achieved by: | ||
Line 27: | Line 27: | ||
* Adding a '' | * Adding a '' | ||
* Adding exception classes '' | * Adding exception classes '' | ||
+ | |||
+ | Fibers allow for transparent non-blocking I/O implementations of existing interfaces (such as PSR-7, Doctine ORM, etc.). This is because the placeholder (promise) object is eliminated. Functions instead can declare the I/O result type instead of a placeholder object which cannot specify a resolution type because PHP does not support generics. | ||
==== Fibers ==== | ==== Fibers ==== | ||
Line 47: | Line 49: | ||
A Fiber would be represented as class which would be defined in core PHP with the following signature: | A Fiber would be represented as class which would be defined in core PHP with the following signature: | ||
+ | |||
+ | < | ||
<code php> | <code php> | ||
Line 220: | Line 224: | ||
=== Fiber Stacks === | === Fiber Stacks === | ||
- | Each fiber is allocated a separate C stack and VM stack on the heap. The C stack is allocated using '' | + | Each fiber is allocated a separate C stack and VM stack on the heap. The C stack is allocated using '' |
===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== | ||
Declares '' | Declares '' | ||
- | |||
- | ===== Proposed PHP Version(s) ===== | ||
- | |||
- | PHP 8.1 | ||
===== Future Scope ===== | ===== Future Scope ===== | ||
- | === suspend keyword === | + | The current implementation does not provide an internal API for fibers for PHP extensions. This RFC focuses on the user space fiber API. An internal fiber API will be added, collaborating with other internal developers and using feedback from PHP extension developers, including Swoole, so fibers can be created and controlled from PHP extensions. An extension may still optionally provide their own custom fiber implementation, |
- | '' | + | ===== Proposed PHP Version(s) ===== |
- | // | + | PHP 8.1 |
===== Proposed Voting Choices ===== | ===== Proposed Voting Choices ===== | ||
Line 566: | Line 566: | ||
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 [[# | + | 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? === | ||
Line 583: | Line 583: | ||
As noted in [[# | As noted in [[# | ||
+ | |||
+ | ===== Vote ===== | ||
+ | |||
+ | Voting started on 2021-03-08 and will run through 2021-03-22. 2/3 required to accept. | ||
+ | |||
+ | <doodle title=" | ||
+ | * Yes | ||
+ | * No | ||
+ | </ | ||
===== References ===== | ===== References ===== |
rfc/fibers.txt · Last modified: 2021/07/12 21:30 by kelunik