Hi Peter, Thanks for the feedback!
On Wed, Mar 17, 2021 at 3:02 AM Peter Stalman <sarke...@gmail.com> wrote: > > On Tue., Mar. 16, 2021, 13:58 Josh Di Fabio, <joshdifa...@gmail.com> wrote: >> >> Fibers will not make those issues obvious at all. The issues I'm >> describing will only crop up spontaneously and under load. > > > Hi Josh, > > Is this really that big of a concern though? The issue will only be a > problem if it's run inside an event loop/scheduler that the concerned library > is compatible with. In which case the developer should be well aware of what > is involved. Not exactly, no. As a library author, code you wrote without fibers in mind can become async. 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. > Your average unaware developer can continue to happily use any libraries they > want without encountering any async issues. The calls from outside the > library will still be blocking, as PHP will still be single threaded. > > Thanks, > Peter > > I feel like we're going round in circles a bit, and I don't want to drown everyone in emails, especially as we're out of the discussion period for this RFC. I will try to clarify my point and attempt to summarise the counterpoint to reduce noise. My opinion is that, in a world of multi-vendor applications and dependency injection, async can't safely be an implicit feature, it needs to be explicit. It should be noted that virtually all general purpose programming languages seem to take this view, including, for example, hacklang. The counter argument is: if you want to use fibers, you have to be sure that your entire codebase, *including all of the code you import from other vendors*, is written with fibers in mind (or is compatible by good fortune). But this will not be made explicit in the code. I think this is wishful thinking, and highly impractical. And finally, to clarify one other thing, the bugs I'm talking about are race conditions. You don't identify race conditions by executing code, you find race conditions by reading code. So all of the code has to be read in order to find them all, there is no shortcut. Most people won't actually do this however. Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
