On Tue., Mar. 16, 2021, 23:49 Josh Di Fabio, <joshdifa...@gmail.com> wrote:
> Imagine for a moment that you create a library, awesome-library-x, > which uses a PSR logger internally. You will most certainly allow that > logger to be injected into your library. Now imagine that some other > developer uses awesome-library-x in their application, and injects it > with a monolog logger that logs to some AWS service via the AWS SDK. > In turn, that logger indirectly uses Guzzle, which adds fiber support. > As a result, any functions in awesome-library-x which log something > become asynchronous. Two changes made by two developers unrelated to > awesome-library-x cause its code to be executed asynchronously. > > > Otherwise, if the library uses fibers internally it will have to resolve > them itself before continuing, no? If `capturePayment()` starts a fiber > then execution will not get to `setTransactionId()`, until it completed or > is handed of to a scheduler (again, which the developer would be aware of. > > > > So I don't think developers will face this race condition, unless they > are using framework like amphp and reactphp. But that's already the same > now, so if it's an issue it's not a new one with this RFC. > > It is a new issue. Today, interruptible functions must include a > `yield` statement, so they are explicitly interruptible. > No, they don't need to yield. You can do `$guzzleClient->requestAsync()` today, so how is it different? Thanks, Peter
