Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:126640 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 7518E1A00BC for ; Sat, 8 Mar 2025 10:42:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1741430403; bh=ruxbcXtZ8tP4xkeLuj12AiK6QFjqDAG55SRX6TlgA+s=; h=Date:From:To:In-Reply-To:References:Subject:From; b=Y5Jl8sm0vNF7+rqyuEvbl0FH9LaTwqSMYD8YIc8XBpNgUBh6wfzYuIsx9z21G9cbg FDui/iRGjogIgKqCNA27vOYvU5GbeIypp+juEEOG1ppqC2QkfsP5KxtdSCry7o3Ldo xCWOzV4ewcWvQzcc9zz762tr/LPIZ9nv4yD7elDUDXOuwCcKa2aUZYP1X6GzZEWrwC ibQzdDz+TTeVSZ57axISaOabVprxlI7+6nO6ODRon6ADWUxBBmiYrUuIJqUa+CtYkv tPJ17LE5A2AHwB9Ff1GC9uGnckDgd80SAMHCk9SsvcsrWfxpAOCwNXBH20COl20EOI +XbH8lo+spRDA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 71F85180088 for ; Sat, 8 Mar 2025 10:40:01 +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=-0.2 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_20, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,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 sender4-of-o52.zoho.com (sender4-of-o52.zoho.com [136.143.188.52]) (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:40:00 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1741430553; cv=none; d=zohomail.com; s=zohoarc; b=ZSvhDWi/GZyMpYSFsQmy1YQxXiO6u5FmWmmuFAYIC26ejazE9lfqjATujjtpfEiHwJ0Y1ymLFu5ySGGgnCCzKkPHTREBHg5eBc6ZR2kRI6fkRJtUYPE5ofpD1DWnN9CSkPw7om7CX84naTsVtFAAWrJF5EPY8TwnhH06V4viHFA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1741430553; h=Content-Type:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To:Cc; bh=kCh2uqv/QMVpFBFdpkrOu35pbzKm7H68kwiTlRBLjpI=; b=MTvh/cYqURXK0o7tPJ3cQGwrW7L3o/VhYyVFsQx4jHjKUoMWMjwxsCrh5c2F/5qdhvAa2LMjojNELOgTgywRUk9ScfjZWZsqi8DFtpXC3bgGQy5c/MtYZqIfRjwUYsLWPt+7cW2j3+ALnzAZhhZ3iK8VkWN7kpi1g3lm17pBlLo= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=daniil.it; spf=pass smtp.mailfrom=daniil@daniil.it; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1741430553; s=daniil; d=daniil.it; i=daniil@daniil.it; h=Date:Date:From:From:To:To:Message-ID:In-Reply-To:References:Subject:Subject:MIME-Version:Content-Type:Message-Id:Reply-To:Cc; bh=kCh2uqv/QMVpFBFdpkrOu35pbzKm7H68kwiTlRBLjpI=; b=QcySbBYbmUQdwWj1Q64wDM/kcQObv6xr+J2nXUx40HZRDqY5um86E8iWjtf+yb/Y nJExhcxwmn+evH/yGjC36FjUO+zro7pMax44ffqXUH9CZqraHbuhVge8qUz4L4bhDMF YoK7XQcSMTwdq0VRbHMqg5Bkeq5yqbFB/KMjxklk= Received: by mx.zohomail.com with SMTPS id 1741430550621439.031782836101; Sat, 8 Mar 2025 02:42:30 -0800 (PST) Date: Sat, 8 Mar 2025 11:42:26 +0100 (GMT+01:00) To: internals@lists.php.net Message-ID: <5e3bbe6e-18b1-4b7e-a1f0-bf143b5b93b6@daniil.it> 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_5_102616181.1741430546860" X-Correlation-ID: <5e3bbe6e-18b1-4b7e-a1f0-bf143b5b93b6@daniil.it> X-ZohoMailClient: External From: daniil@daniil.it ------=_Part_5_102616181.1741430546860 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. ------=_Part_5_102616181.1741430546860 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.
------=_Part_5_102616181.1741430546860--