Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113571 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 84049 invoked from network); 16 Mar 2021 18:26:49 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Mar 2021 18:26:49 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8ACB51804C0 for ; Tue, 16 Mar 2021 11:20:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.221]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 16 Mar 2021 11:20:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1615918835; cv=none; d=strato.com; s=strato-dkim-0002; b=qRoWl+4/Zp2uq0f3ZqEsPGY21lfQ3XbAOfVBLLmni6g69+sZ6vV7VlMQ/BgnOyA91T xErjMcV3V9mdXHXRC55owDgK6GCnGBQXfBi+Z5BrvY4sEgp9AOvDPkBpaPUhdlAqVYhB 2Vh0uAMv0zXobChiVNyiyuyu4dWlJ79fv2/dJn7D4kYWF3pympbXCI3wDI952se0JZKH lWcAzUNE/tbb/RrtvWuMGOk2fVu2AUyjYTaOJEMQ40NbApbhsf4zOYG+x0dvNcQBddVw AU6lQu3mGoWS/ml94GR6l1tqSAI6eo6udDo3TQriZFoNmftNqamZTfpjG7UJ/tFQP7Jv aCeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1615918835; s=strato-dkim-0002; d=strato.com; h=Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:Cc:Date: From:Subject:Sender; bh=rdd4QjZqgWo4myX8S3m/9I8OhjYkgT0IY0+SIsknfL4=; b=OYQZOOKaJAd/vWEiHit6fr5/7OGtTLthWTZsLjJ7w83b7FOa7rvCD2DyLVpuJVLOrA pn7knqmrhnSK1vo3wcdNTcizRBuBHxFdO6e46qSpiix9lGdRiN+MropvvLexpQVDr1ba 7S0ZDiHoyvcDYJS2Miv5/uL9h6RmoxyY3vwidrYh9pcVSLwMUPcq3a/tP0sLM/Z/FPQe yRCfw/gcVKT3YKwMbsOT05ttz2aS2M6cd81tZyqMCsMKWHJFZRM+3Ou7thCM6rJgCtqm IhMCE5Ya1o67sFPLpVx3X5y91ntdmHyBN6/9v7/NP7EJTtjrL5s6k4KBlP2VbA7CiffD VLPw== ARC-Authentication-Results: i=1; strato.com; dkim=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1615918835; s=strato-dkim-0002; d=kelunik.com; h=Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:Cc:Date: From:Subject:Sender; bh=rdd4QjZqgWo4myX8S3m/9I8OhjYkgT0IY0+SIsknfL4=; b=XBOY2EJ45zZY5SuKmqSZMBIANjcCOmmwtrZlKDIdmgjNolDsyMjWozTyjWqVvHSPKx mBfUU5ZhVqn7nXTu3l5sCieSqfFZIz/baWGhPxeokShtqgizH7qgYVBlkdAJCGPJiV1P sJZ9rbWTr4S7ygeoNXKUvlkusnkhqVY3P5eLphTKZWb/ZnmXccV63MAMycaZyS+yz25G Ml6L80kjRyLJE4CCsIc0dJkYe8LOs0AFQfjf7isbqy6QeQFWiPZKtjwCEDnyap9wPY9q nvrSllEU2KBL6pakUadkqZk+2vf10O54y3WtilNKkD4sZrJAsLc+qFDV7CNhOGEwn3i8 lw6w== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":IWkkfkWkbvHsXQGmRYmUo9mlsGbEv0XHBzMIJSS+jKTzde5mDb8AaBAcYiVB" X-RZG-CLASS-ID: mo00 Received: from mail-pj1-f52.google.com by smtp.strato.de (RZmta 47.21.0 AUTH) with ESMTPSA id j0836ex2GIKY70C (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Tue, 16 Mar 2021 19:20:34 +0100 (CET) Received: by mail-pj1-f52.google.com with SMTP id k23-20020a17090a5917b02901043e35ad4aso1756908pji.3 for ; Tue, 16 Mar 2021 11:20:34 -0700 (PDT) X-Gm-Message-State: AOAM530qshdirRtZrREzfCQmPdZi3P7gAzZM7fuZ7ghR2Diaq1i5zhnq VUy/5xNtewZBixU5S8A3ugykn74wMYDRlGhEr0g= X-Google-Smtp-Source: ABdhPJwerrJM0sHAEG3B+rIwoMEeTGWy3Mbnwl8oM+kEnXvFHPHMYnnAqb/zadkP4/F7LXezHd12HxiO8WMRMv56xJM= X-Received: by 2002:a17:902:a505:b029:e6:7a98:691b with SMTP id s5-20020a170902a505b02900e67a98691bmr750639plq.84.1615918834020; Tue, 16 Mar 2021 11:20:34 -0700 (PDT) MIME-Version: 1.0 References: <70951423-5e77-c150-6dce-dd3c62f8dc8b@php.net> <0b994a60-7970-605b-1657-d6ee732690e5@gmx.de> <5C73A1DE-E563-4F69-B8C7-6506F81D7345@trowski.com> In-Reply-To: Date: Tue, 16 Mar 2021 19:18:13 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Josh Di Fabio Cc: Aaron Piotrowski , "Christoph M. Becker" , Michael Wallner , php internals , Derick Rethans Content-Type: multipart/alternative; boundary="00000000000016775a05bdab6c99" Subject: Re: [PHP-DEV] [VOTE] Fibers From: me@kelunik.com (Niklas Keller) --00000000000016775a05bdab6c99 Content-Type: text/plain; charset="UTF-8" Hey Josh, > Apologies, this is a long one! > > This RFC strikes me as being very dangerous. Implicitly allowing code > which is synchronous by design to be executed asynchronously seems > sure to lead to very subtle, unpredictable, confusing and dangerous > bugs. > Thank you for sharing your thoughts, I'll respond inline for better context, but shortened some paragraphs for better readability. > [...] > > For example, the PHP ecosystem is full of code like this: > > private function capturePayment() > { > $paymentRequest = preparePaymentRequest($this->currentOrder); > $this->paymentGateway->capturePayment($paymentRequest); > > $this->currentOrder->setTransactionId($paymentRequest->getTransactionId()); > } > > In the above code snippet, the developer has relied on the fact that > the mutable value $this->currentOrder will be the same before and > after the call to $this->capturePayment() [...] > This is a very valid concern to have. However, this code won't simply break if executed asynchronously. It only breaks if the same method (or other methods making use of the same state) is executed concurrently on that object. > [...] > > - These race conditions will cause problems so rarely that developers > will not even realise that their programs contain dangerous bugs. [...] > - Changes very, very far away from your code can cause your code to > become unexpectedly asynchronous. [...] > - As a library author, there is no way of knowing how your code is > going to be used, and what injected dependencies might use fibers > internally. > > The counter arguments: > - "The above code snippet is suboptimal, it shouldn't assume that > mutable state remains unchanged following some IO, and the order > should be passed in as an arg." [...] > - "Fibers should only be enabled in async first programs." and "We > could flag that certain libraries are fiber compatible or > incompatible." [...] > > Consider the following: > > private async function capturePayment() > { > $paymentRequest = preparePaymentRequest($this->currentOrder); > await $this->paymentGateway->capturePayment($paymentRequest); > > $this->currentOrder->setTransactionId($paymentRequest->getTransactionId()); > } > > Looking at the above code, I can see the race condition. It becomes > explicit. So I change the code and communicate explicitly via the type > system that this function is asynchronous and that my code expects > PaymentGateway::capturePayment() to be asynchronous. > If you can see the race condition here, you can probably also see the race condition in the original snippet above. The overall issue you're describing is thread safety and mutable state. It exists with fibers, but a very similar issue exists with explicit async / await. Just because something supports asynchronous I/O, doesn't mean it also supports concurrent operations on its state. It might be a good idea to introduce some guarding concept in a follow-up RFC, so objects can easily protect against being used concurrently e.g. ``` private synchronized function capturePayment() { $paymentRequest = preparePaymentRequest($this->currentOrder); $this->paymentGateway->capturePayment($paymentRequest); $this->currentOrder->setTransactionId($paymentRequest->getTransactionId()); } ``` "synchonized" isn't the right keyword here, but I can't think of a better name right now. > Regarding PHP's type system not supporting generics, and the > associated advantages of this RFC over promises; I agree that this is > a problem with promises. But the lack of generics in PHP already means > we have no language-level type safety on data structures, which is > certainly worse than not having type safety on promises. Psalm et al > have provided reasonable solutions to this issue. > Being able to use the type system is a concern the RFC solves, but that's rather just nice-to-have. The relevant problem is the call stack pollution or "What color is your function" problem. It simply doesn't make sense for applications and libraries to offer an async and non-async interface for everything. Due to the "What color is your function" problem, there can't be a gradual migration to non-blocking I/O, which will mostly result in non-blocking I/O simply not being supported by the majority of libraries, making it basically non-viable in PHP. Best, Niklas --00000000000016775a05bdab6c99--