Hi Peter, Thanks for clarifying.
On Thu, Mar 18, 2021 at 2:43 AM Peter Stalman <sarke...@gmail.com> wrote: > > On Wed, Mar 17, 2021 at 7:41 AM Josh Di Fabio <joshdifa...@gmail.com> wrote: >> >> Note the difference between the two. Also note how, in both of the >> above cases, the asynchronicity is explicit and the developer has >> opted into it. Both of the above are different approaches to that >> being proposed in this RFC (this is a design choice by the authors). > > > Hi again Josh, > > I think we are jumping back and forth on two different things. One is the > race condition caused by async, and the other is if the top level code > explicitly states that it is called asynchronously. > > When I used the Guzzle `requestAsync()` example, it was meant to show that > you can have a library do something, and then continue execution like it had > completed when in fact it had not. This could cause your > `setTransactionId()` to happen before the `capturePayment()` request has > completed, and in that regard it can be the same; not by how it works, but in > concept. I do know that they are different in implementation. It would > cause this without an explicit keyword showing that `capturePayment()` used > an async call internally. That is what I was referring to when I said it > could also be a race condition now, without fibers. > > As I was also explaining earlier, the developer must know that they are > inside an async environment, because you can't suspend the main "thread". > `Fiber::suspend()` only works inside of a fiber, and for that to happen you > must have run it inside of a framework that can schedule and resume these > calls. To reiterate my earlier point, the average PHP developer will not be > in a place where this would ever occur out of the blue for them. It's not > going to surprise them, and even though it might not have an `await` or > `yield` keyword in front of them, the developer cannot be unaware that they > are inside an event loop that can resume fibers. > > I am arguing against you saying this RFC is "very dangerous", because this > feature can only be dangerous if you use it. It's like saying `exec()` is > very dangerous, because you can screw up all sorts of things with it. But it > is only dangerous if you use it without knowing what you are doing. > > Thanks, > Peter > > I understand your view; it's the same view that others have expressed here including the RFC authors. I believe it is fair to paraphrase as, "If you want to enable fibers in your application, you must be confident about the implementation details of all of the code in your application, including that of your dependencies, which are written and maintained by other developers." I don't have anything to add to my previous point in that I disagree that this is practical. Thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
