Add async support using php-tokio

[danog]

No description provided.

[joelwurtz]

Having async which support fiber is definitely a blast however i'm not sure this is the right way to do that, as you have a dep on php-tokio that have a dependency on this library, not a fan of circular deps even if it's well done by rust here. Also i don't think it should have a direct dependencies on tokio as there are other async runtime in rust, why not do the following :

• Add code from php-tokio directly in this lib in a "async" crate
• Split this async crate in two :
  • Wrap PHP Fiber with Future from rust
  • Add a tokio feature providing an event loop (which depends on tokio)

[danog]

Hi, I actually wrote php-tokio as part of a previous PR to ext-php-rs, I split it into a separate library and removed it from the PR because I felt it introduced code (interacting with a userland library like Revolt, macro transmute black magic) that had no place in ext-php-rs (which is a library that interacts with the Zend API).

I'll very gladly add a separate async feature for it (and I eventually plan to add support for other event loops other than tokio), but I'd like to include it as a separate crate from my repo, given that I'm a maintainer of both ext-php-rs and php-tokio.

[danog]

Actually, the cleanest solution imo is just to mention in the docs as a peer dependency to add async support, switched to this solution for now.

[danog]

The main reason I feel like it's the best solution is because it's basically an adaptor for the revolt event loop, not really something related to pure PHP itself (and that's because PHP has no event loop, thus there is no way to implement this using only PHP APIs in a way that's compatible with the current PHP async ecosystem).

[danog]

I.e.

Wrap PHP Fiber with Future from rust

We can't wrap Rust futures using pure PHP fibers, because the result would be yet another competing event loop implementation (and one that's not compatible with any of the implementations currently powering the async ecosystem, namely Amphp and reactphp).

On the other hand, relying on Revolt introduces a userland dependency, but allows for full compatibility with amphp, reactphp, psl and any other library based on revolt.