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'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, even 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`.
That is literally the "What color is your function" problem.
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. If that's not the case, you have a
buggy codebase already even without fibers. Fibers would just make it more
obvious.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
