> On Mar 19, 2021, at 3:55 PM, Rowan Tommins <rowan.coll...@gmail.com> wrote:
>
> On 18/03/2021 09:20, Josh Di Fabio wrote:
>> "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.
>
>
> While I agree that this is extremely difficult, and slows adoption of
> asynchronous technologies, I think the challenge is not identifying
> asynchronous code, it's identifying shared state.
>
> In your example, you show code that was written to use shared state
> unwittingly calling code that was written to be asynchronous:
>
> private function capturePayment()
> {
> $paymentRequest = preparePaymentRequest($this->currentOrder);
> $this->paymentGateway->capturePayment($paymentRequest);
> $this->currentOrder->setTransactionId($paymentRequest->getTransactionId());
> }
>
> However, the same problem exists the other way around - code written to be
> asynchronous unwittingly calling code written to use shared state:
>
> private async function capturePayment()
> {
> $paymentRequest = $this->someDependency->preparePaymentRequest();
> await $this->paymentGateway->capturePayment($paymentRequest);
> $this->someDependency->setTransactionId($paymentRequest->getTransactionId());
> }
>
> This all looks fine - but what if someDependency is actually calling into a
> library which stores the current order in a static variable? Now you have
> exactly the same race condition for the opposite reason. And the solution is
> the same: carefully vet all your dependencies.
>
>
> I can think of a few ways of solving this:
>
> 1) Require all the code to be synchronous. This is easy in PHP, even if
> Fibers are supported: just don't run in an asynchronous framework.
>
> 2) Require most of the code to be synchronous. This is the common approach of
> labelling functions as "async" or converting return values to Generators or
> Promises. The big disadvantage is that it requires rewriting a lot of code
> that doesn't care one way or the other if it's called synchronously.
>
> 3) Require all the code to be free of shared state. This is ultimately the
> only way you'll get the full advantage of asynchronous code.
GoLang uses goroutines for this.
Goroutines allow code written by responsible developers for use by others to
ensure their packages are safe for consumption by others. The Go mantra
related to concurrency is "Do not communicate by sharing memory; instead, share
memory by communicating."
https://blog.golang.org/codelab-share
Having experience with Go, channels work brilliantly for allowing concurrent
routines access to the same data, albeit in a controlled manner.
> 4) Require most of the code to be free of shared state. Having some
> primitives in the language to mark out code that definitely *can't* be
> asynchronous would probably be useful. Perhaps you could mark a function as
> "no-interrupt"; this could then be used as a wrapper when calling into a
> library you know or suspect of using state in unsafe ways.
>
>
>> 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.
>
>
> Although this would avoid keeping both synchronous and asynchronous versions
> of the same function, it would require adding that keyword to every single
> function call, just in case somewhere inside it wants to take advantage of
> your asynchronous environment.
>
> From my limited understanding, goroutines are a completely different concept.
> Saying "go someFunction()" in Go immediately starts a new thread-like thing,
> and doesn't return anything. The runtime manages the scheduling of the
> thread, but if you want to get any data out of the goroutine, you have to
> pass it explicitly, e.g. via a channel.
Just in case it is relevant for anyone reading this discussion who is not
familiar with Go this short article compares and contrasts goroutines vs.
threads:
https://www.geeksforgeeks.org/golang-goroutine-vs-thread/
#fwiw
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
