Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:126641 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id E91631A00C1 for ; Sat, 8 Mar 2025 10:44:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1741430532; bh=g5MMT3E/y0Mtpe7NoG4z9z9UAP36GdeseAU2jze4NDU=; h=Date:From:Cc:In-Reply-To:References:Subject:From; b=gMrrOBYEs8L6R2goacoW485lt1AhbEHCdC6tPt/X1YSOx2lOBLyrvhzOa9lSpnnbo HRaD2D3TZMkUtcs7PfGAQD50eM2+XxsT64AnWK/QYTBD4N/4mYeAe40gDDGctfy0eI DBGzgRytEgZa+P9M+fFLTNFjELkO1yLYfM0LMd5I4ENBTo3O0sSZkM+bQdV7P54goc 2eoJ1RQLfbvwyq2S4h2Mjipm3HBMvioiaPJLZOec1eyGu/VGbeu2nvlUTNoAhqyzN4 GetCq5e3nk6CeMDjWE7GlOwv2kdEuqOGqiroAMC9SOgvaTjgSV3H4ZnfmkTxM2S0Wm rNCEsDYSatrDg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B8BEA1801ED for ; Sat, 8 Mar 2025 10:42:09 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: *** X-Spam-Status: No, score=3.8 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,MALFORMED_FREEMAIL,MISSING_HEADERS,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 8 Mar 2025 10:42:06 +0000 (UTC) Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-aaec61d0f65so547041866b.1 for ; Sat, 08 Mar 2025 02:44:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741430680; x=1742035480; darn=lists.php.net; h=mime-version:subject:references:in-reply-to:message-id:cc:from:date :from:to:cc:subject:date:message-id:reply-to; bh=vbdqxyMS5fg5yZULMZ59D98lQH1yB41GJMPXD0lZlmk=; b=hiboL2eSJQNbEcTiylRxP5//1Mow6AxolmVhF2Pxy7K3WuC0iXQqZQuowsln+DX0su 0pAzoJbP5OOn+FcXLqzM8J0yLXosrprNsBYQW4odpyDq36eYEW3yUp49uCLB42RW6Sa8 JkJUz5GRfF6asA05J7Qz85trrqfO8eaI1rmCgN1seYsrmkzac+C+YymWVfWjaYKs4eJT JhHWxSyUfQFfpkSFASiNDArqpcgo76mN7s//TlTmW6fnuKZzQC6TKt1uxBApXfxP1HtG l4eC248tqjiTKw10hJqKPdkQ+v7032bciGpH4LfoWuhkPqsEs/PFNQOCKBMaKCe7HNNy be/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741430680; x=1742035480; h=mime-version:subject:references:in-reply-to:message-id:cc:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vbdqxyMS5fg5yZULMZ59D98lQH1yB41GJMPXD0lZlmk=; b=IOg4DtDFzr7hTXu2yE7iRRxcbCMu8Lw5iJV2YZdFg2YgwGfUpkVcB4vM+dy/ozYojJ /ff2XhXflolgOzRa36JtJW0/5HOYdWCLXNJfIOcpPeNhEA77iHpaGmrKJMXutimrbPCm Z1ETjlQtXRlJV03DzmaO89E6KPpw5ewMnG+t75c7TDczdmMW3gJme3nt9MMlf8XnZf3R 9D8o0lJZzWRPf1kp4fCq9k6ZpEHfLeK18j7Pn1xp6lLxnxeDd5Pkj2Fe1nDPdqWlsw8K dx44N501wyNDM51SdDDgf+qfHhwCl+mMxEq3cvGyqMTFV9qvMaC+a170MgUPlW+gzZkv cgOQ== X-Gm-Message-State: AOJu0YwFEYM9T+eooow8xvU1iyHFqodgXrx5uIbhLIpsqUKhL+1t2FII JNI0chXsrx1It9uzjpucTxFWpFQ3eE3XUF2WZC84kXZtOjEkFaJ06hpmWg== X-Gm-Gg: ASbGnct3ZJ02yBQCedGEs8reFPZyvlXKFbEFc9v3YrKJkqDJtaAhZ33AORqp2KYs5X5 vte7NhUxC1zNm7/59HNG56XktxMvfGnPPL2sG7YWldy22QO+QjPu9+emVTTDp2AaSvc9X+AZkMF DRq4x5deFlTHoBQi/ykV2X0WLNmaTNvn2dYGrWS/5J7+++xRKUxXOWoORN+cxnFJ7VT8GeI6bgz PcoegUXlTUKFlVg+HvYzjN1BKmo+77O839CJD1kT5FB8jFA9reSsZDCoVkSewYgON6TpGoOVyQV oSqBQqgzH1aT+NbwN9xUArNWsasWN5JIcrCCATVS0yytJLgvwaevs84Fs2L9N82CjNxUnB4U+Cj mL996jqnYgA+pUrgo6BiJ084V6u0F X-Google-Smtp-Source: AGHT+IGW2cHdaZdlnFfTn/evKj/iyX4K651tF/ipT/cf51KzborWdqidwjyMgTXt3mADIrDlEV7QhA== X-Received: by 2002:a17:907:2d11:b0:ac2:4579:3686 with SMTP id a640c23a62f3a-ac252ba0950mr723742766b.41.1741430679713; Sat, 08 Mar 2025 02:44:39 -0800 (PST) Received: from ?IPv6:::1? (luna-749a6f85f554075d0000f.net.as198747.daniil.it. [2a0e:97c0:38f:0:d570:455f:58f6:a947]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac239438758sm413079766b.25.2025.03.08.02.44.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 08 Mar 2025 02:44:39 -0800 (PST) Date: Sat, 8 Mar 2025 11:44:35 +0100 (GMT+01:00) Cc: PHP Internals Message-ID: <8599eb8b-d4a3-4cb8-899a-25b134e0d64d@gmail.com> In-Reply-To: References: <9964db8c-0ffe-43d5-8246-47fc76b07180@app.fastmail.com> <78a03dd0-fd4a-4f4a-ad8a-37e5704f06fc@app.fastmail.com> <08c8ad0b-e8f4-46e3-99f0-b80748d40b89@app.fastmail.com> <07973EAE-2D83-47A8-8FA0-84286C77C02B@rwec.co.uk> <48d66433-3ae9-4895-8361-7c81a0a3670d@app.fastmail.com> Subject: Re: [PHP-DEV] PHP True Async RFC Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_14_110814749.1741430676113" X-Correlation-ID: <8599eb8b-d4a3-4cb8-899a-25b134e0d64d@gmail.com> From: daniil.gentili@gmail.com (Daniil Gentili) ------=_Part_14_110814749.1741430676113 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > In my opinion, colored functions is the worst thing that could happen to PHP. > > https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function > Describes quite expressively what's wrong about this approach. > > This is going to be a ton of changes, when currently sync (blue function) will have to become async (red one). > > The way amphp goes - it's the right way. They have had this problem of red-blue functions a long ago until Fibers came into place. > > > This is just annoying, and IMO should not be considered. +++++ on this, the discussion on this RFC is veering in a very annoying direction for absolutely no good reason. Golang has shown and proven that we do not need colored functions to make use of (extremely simple to use) concurrency. Please do not cripple the adoption of async php by making it colored and by adding absolutely useless async blocks, forcing everyone to rewrite their codebases for absolutely no *good* reason, when with the current colorless, fiber approach the only thing that's needed to adapt current codebases for async is the usage of channels and a few appropriately placed synchronization primitives (I know this from experience, migrating a large and complex codebase to be fully async). The only thing that's truly needed in this RFC is a set of synchronization primitives like in golang, and a way to parent/unparent fibers in order to inherit cancellations (as previously mentioned in this list), not contexts, async blocks and colored functions. Any issue around $_GET/etc superglobals (i.e. to handle each incoming request in a separate fiber) should be solved at the SAPI level with a separate RFC, not by introducing contexts and async blocks and making concurrency harder to use. I like and use immutability, but it has it limits, it should not be used everywhere, and it should not be forced upon everyone just because someone is a strong proponent of it. Regards, Daniil Gentili. (Resent again as the other email has deliverability issues on the list). ------=_Part_14_110814749.1741430676113 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit > In my opinion, colored functions is the worst thing that could happen to PHP.
>
> https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function
> Describes quite expressively what's wrong about this approach.
>
> This is going to be a ton of changes, when currently sync (blue function) will have to become async (red one).
>
> The way amphp goes - it's the right way. They have had this problem of red-blue functions a long ago until Fibers came into place.
>
>
> This is just annoying, and IMO should not be considered.

+++++ on this, the discussion on this RFC is veering in a very annoying direction for absolutely no good reason.

Golang has shown and proven that we do not need colored functions to make use of (extremely simple to use) concurrency.

Please do not cripple the adoption of async php by making it colored and by adding absolutely useless async blocks, forcing everyone to rewrite their codebases for absolutely no *good* reason, when with the current colorless, fiber approach the only thing that's needed to adapt current codebases for async is the usage of channels and a few appropriately placed synchronization primitives (I know this from experience, migrating a large and complex codebase to be fully async).

The only thing that's truly needed in this RFC is a set of synchronization primitives like in golang, and a way to parent/unparent fibers in order to inherit cancellations (as previously mentioned in this list), not contexts, async blocks and colored functions.

Any issue around $_GET/etc superglobals (i.e. to handle each incoming request in a separate fiber) should be solved at the SAPI level with a separate RFC, not by introducing contexts and async blocks and making concurrency harder to use.

I like and use immutability, but it has it limits, it should not be used everywhere, and it should not be forced upon everyone just because someone is a strong proponent of it.

Regards,
Daniil Gentili.

(Resent again as the other email has deliverability issues on the list).
------=_Part_14_110814749.1741430676113--