Hi Larry,
Thanks for the feedback. Replies inline.
On Tue, Mar 16, 2021 at 8:33 PM Larry Garfield <la...@garfieldtech.com> wrote:
>
> On Tue, Mar 16, 2021, at 1:44 PM, Josh Di Fabio wrote:
>
> > Perhaps we could rather make fibers *opt in* at the *callsite*
> > (similar to goroutine calls) in order to prevent functions
> > unexpectedly being executed asynchronously due to faraway changes.
> > This would be safe and predictable while also avoiding the "What color
> > is your function" problem. For example
> >
> > private function capturePayment(): void
> > {
> > $paymentRequest = preparePaymentRequest($this->currentOrder);
> > // allow, but don't require, the underlying call to use
> > fibers. Callers higher up the stack would also have to opt in
> > async $this->paymentGateway->capturePayment($paymentRequest);
> >
> > $this->currentOrder->setTransactionId($paymentRequest->getTransactionId());
> > }
> >
> > With this approach, APIs we'd avoid the "what colour is your function"
> > problem without sacrificing the safety that we really need in e.g.
> > ecommerce.
>
> "Callers higher up the stack would also have to opt in" is precisely and
> specifically the design flaw that fibers avoid.
What you are calling a design flaw, is by far the most common approach
to async in other languages.
> What you're suggesting is that a given IO call would become magically
> non-blocking iff its entire parent call stack was called with `async`
> keywords, which could be 50 stack frames easily. Aside from the
> implementation challenge, and the fact that it would require two different
> code paths even in the PHP code around that IO ...
This is already the case with the fiber RFC as it stands. If you are
not within fiber context, then calls to fiber-enabled are sync. If you
are within fiber context, they're async.
> ... event if it could be implemented it would mean that basically no IO code
> would ever run async, ever, because there is one function call somewhere in
> the stack that didn't include `async` in some library that everyone uses but
> hasn't been updated to prefix every single function call with `async`.
This is very close to how goroutines work in Golang.
> That is literally the "What color is your function" problem.
Some of the "problems" are still present, but I am still suggesting
that there be only one implementation of each function, rather than
two, and that implementation can be called from either a synchronous
or asynchronous context.
> I should also note that if you are following good practices to begin with,
> your code base is 90% pure, immutable functions/methods and so entirely safe
> from cooperative multitasking race conditions.
Right, but that code should generally be synchronous, because if a
function is async then it's doing IO and isn't a pure function. But
note that as this RFC stands there's no way to know that without
actually reading all the code. Perhaps you are rather talking about
side effects, it's unclear.
> If that's not the case, you have a buggy codebase already even without
> fibers. Fibers would just make it more obvious.
Fibers will not make those issues obvious at all. The issues I'm
describing will only crop up spontaneously and under load.
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
Cheers
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
