Re: [VOTE] Fibers

Hi Peter, Thanks for clarifying. On Thu, Mar 18, 2021 at 2:43 AM Peter Stalman <sarkedev@gmail.com> wrote: > > On Wed, Mar 17, 2021 at 7:41 AM Josh Di Fabio <joshdifabio@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