Hi Edmond,
Thanks for sharing the huge amount of work that went into this!
I would really prefer it to be always enabled, no fallback at all, because
> as I said, it will make absolutely no difference to legacy, non-async
> projects that do not use fibers, but it will avoid a split ecosystem
> scenario.
>
>
> I'm not arguing at all that avoiding the call to this function is a good
> solution. I’m on your side. The only question is *how* to achieve this
> technically.
>
> Could you describe an example of *"ecosystem split"* in the context of
> this function? What exactly is the danger?
>
Not sure it's an answer to this question but in Symfony's HttpClient, we
have an amphp-based implementation that's working both outside and inside
an event loop:
- inside means amphp's scheduler already started, and then each request is
scheduled thanks to amphp's http client
- outside means Symfony's code is going to trigger amphp's event loop
internally.
The target DX is that when outside any event loop, we're still able to
leverage fibers to provide concurrency, for requests only, and when inside
an event loop, requests run concurrently to any other things that the loop
monitors.
Is that something that could be achieved with your proposal?
If not, maybe that's the split we're wondering about?
Nicolas