Add fiber type to better support custom fiber APIs #7105
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds a "kind" field to
zend_fiber_context
to make sure that different fiber implementations do not get mixed up. The new field is set tozend_ce_fiber
for PHP fibers and checked inFiber::suspend()
andFiber::this()
to ensure that these methods can only be called from within a running fiber.The main reason for allowing different fiber implementations is to be prepared for async support that might come to PHP in a future version (or be provided by PHP extensions starting with PHP 8.1). Consider an example like this:
In this case the
async
expression should evaluate into a PHP object that is backed by a fiber but does not expose the same API asFiber
to userland. It would be possible to use the existingZEND_API
to create aFiber
and store that as a property of the new object, but that would be wasting memory for additional objects. While this is feasible in a userland implementation (due to lack of alternatives) it would not be reasonable to implement this in C. HavingFiber
in PHP core is great and it should not be changed / restricted to async-only as there are other use cases for fiber (for example emitting values from deep within a callstack without turning everything into generators).The great thing about this is that one can easily develop an async implementation as a PHP extension (of course without keyword support) and everybody has a chance to try and evaluate it before going for an RFC. It is also possible for Swoole to use the same approach and reuse some of the code that PHP 8.1 provides for their implementation.