Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
From replies to the official PHP internal list the feedback/concern by Swoole members has been the followings. [summarized in my own words] A philosophical one with the Fiber class should not be final, various concerns about the C implementation of it (concerning but this is mostly about the integration with the new internal Observer API, and the lack of a C API for adding co-routines, something which can be amended whenever this proposal is accepted), and an allegedly incompatibility with Swoole. This last point is extremely concerning but seems also pulled out of thin air, as both Swoole and ext-fiber (upon which this proposal is based of) use the Boost assembly files for fibers, therefore I would imagine that when a C API is added, this would become a non issue, but this remains a valid reason to vote against it as in its current state it doesn't provide one.
The CPU scheduler component for sure cannot be done in user-land, but I also have trouble understanding why it is needed, as from my understanding the whole point of fibers is to not rely on OS threads, which can be used by using the parallel extension.
They provide hooks that allow you to adapt legacy code, and there's also packages for specific frameworks like this one: https://github.com/k911/swoole-bundle-symfony-demo. If you're looking to adapt a framework where there isn't such a package such as ZF1 or some proprietary framework your best bet is to look and see what other packages did.