Alternative Fiber Internals Refactoring

[kooldev]

@trowski This is an alternative (and a lot simpler refactoring) to #7085 that achieves some of the goals (1 and 3) stated by @twose without a complete rewrite of the code. I kept everything really simple to make it easily comprehensible. It also allows for pure C fibers and arbitrary context switching for different scheduling models. The C fiber is basically represented by zend_fiber_context while the PHP fiber object is using zend_fiber. I am pretty sure that it is a good starting point for further improvements. I have used similiar in production for more than a year now and it works really well.

I did not remove the ZEND_API for zend_fiber, however it would make sense to come up with a new implementation based on zend_fiber_context that might be more suited for internal use. I have used an API like that for some time and it was really nice for suspending from within PHP streams and function calls. Let me know if you are intereseted in another PR for this and I will try to come up with another PR.

Let's make this work in a way that allows everyone to collaborate and benefit.

[trowski]

Hey @kooldev, this looks like a fantastic starting point for further improvements.

This looks ready to merge IMO. Should we merge this and do another PR using zend_fiber_context for the ZEND_API or do you want to iterate further here?

[kooldev]

Hey @trowski, glad you like it. I am pretty sure that this refactoring is a also a nice step towards making it compatible with a future version of Swoole. I think it will be best to rearrange the ZEND_API in a new PR to keep things simple and comprehensible. Feel free to merge it (or request changes) anytime you like. ;-)

BTW: How do you test that ASAN thingy? (I am doing testing in a debian-based docker container)

[trowski]

I'd like at least one more review before merging in case I missed something.

You can test with ASan by adding --enable-address-sanitizer to configure.

[twose]

Thank you for your work.
Could you explain what are the long-term benefits of zend_fiber_context? It still binds to zend_fiber. I can not understand there is any benefit in separating C fiber and zend_fiber. I don't like this idea at the moment.
The main_fiber is also introduced here, I don’t understand why you can easily approve it here.

[trowski]

We can look at how we might want to combine zend_fiber and zend_fiber_context into one in a future PR (or at least in a way that is reusable). This moves toward that direction where it should be simple to combine them in the next PR if that's what we want to do.

The main fiber has a simple implementation here without hacking it onto the VM stack to avoid an alloc.

Providing both symmetric and asymmetric fiber switching models in the internal API is a fine compromise IMO if it means better collaboration or usability. Most of the conversation in the last PR was just about getting you to understand there was a slight paradigm shift being made.

[twose]

We don't need symmetric fiber model and we can't, we just need the way to replace the main with a fiber.

[trowski]

I've grown tired of arguing this point.

I'll merge this PR and we can move forward with further changes from here. I'd like to see the unified API @kooldev has in mind.