Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:126617 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 E1B9E1A00BC for ; Fri, 7 Mar 2025 09:20:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1741339073; bh=AtB4iQipkc/TN79txNDy+pcWfx88uUVVjVIhfCGY0go=; h=Date:From:To:In-Reply-To:References:Subject:From; b=Yb5cI3wKpH47eHVMp234+nHjAtZDGBq1iPIOB6f2WVGJYAiqlUSiwKpdZ/elju6w+ /KlaTYZDH/CdVG2SDtUxZQrEfZyEn7Nt5PTj5xT5r4EuYs7UnUsbWdsFFkJFyxDL3L 9uCjsFzb9EdgSzIBk9ht9AOh35jgSlWjefMKgoCU4YVnbtAwSAE/aTbf+KlCOEmSGc gKqrMDEWiIJOaLwFeeNQYm2sbPbUJyJmJOSikiEhvocAi27bdR0adB6lbnhVTD8U0u X+kVAr5QwCih4oD+qJ7lJU8At1dPT8xN2FCq+g5OIZC6OWNQRH6RQsrqVF564vL+iK unECwDfSP6hTQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 0F08B180079 for ; Fri, 7 Mar 2025 09:17:52 +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=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from fout-b7-smtp.messagingengine.com (fout-b7-smtp.messagingengine.com [202.12.124.150]) (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 ; Fri, 7 Mar 2025 09:17:51 +0000 (UTC) Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfout.stl.internal (Postfix) with ESMTP id 832481140130 for ; Fri, 7 Mar 2025 04:20:26 -0500 (EST) Received: from phl-imap-09 ([10.202.2.99]) by phl-compute-11.internal (MEProxy); Fri, 07 Mar 2025 04:20:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1741339226; x=1741425626; bh=AtB4iQipkc /TN79txNDy+pcWfx88uUVVjVIhfCGY0go=; b=RKhZrje6+urajwQ20mgxRpmiFI oIDSb7Sd4mSIpix63I2aJtR2ovcppEXcCZi2NTZXr3sUx4uE72B1mgWgpBrYq/fE sa9uFpAToyi9tcCDPcEHzREHKUSL3zpdQzx3iMzRc143tzMxjK+pTZ05XKh2QRkx OlJs9h/5jl59F9grT5cEegvykWlNBlHuMRzGsETNrlK9sNwxDBSnawJLo3tz1DAv H/CO53kLOs9BuPWAtvyVmFpbXM2rqxpG2bTbj2j0HQkC80B5yUO5Vu0/S1HehG/3 2PHsdZvtMzmSwSILTRgdGLO9MCrw9m0yaSw/zF3WycCTglLJsyCyrwpESlBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1741339226; x=1741425626; bh=AtB4iQipkc/TN79txNDy+pcWfx88uUVVjVI hfCGY0go=; b=pwfeHJZJ60qFGgpyr4Z948DqPbw4eq6Diu7ZQlny5xQmV3aeR/D x35Fv1dkNTCJDpin5vN3DxA5eoC9dfS0AECdj7HE/t2DxDQaPG5qsAtf+YiAEeh3 4OexFBUcwgdAHp67K5A5VFoJTIGQH8LtuLXsinmOCWv04PWCfrIKue8VrW/wQNIS Keclfe32udvzEri+pk9SzsWa6kMIYwyQd5lbiWvmNFpR6hz/S4Jn59iATzjGHt11 WhV8/MF4g6I4dfEsRafeYOfWFiprsLPAXf37OGFmd11zp+BNkXvLfyG8wfu4bvWq hEl3sE8b8l17StA0VuQkJ6g/ZluGXriMaEA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduuddtvdekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefogg ffhffvkfgjfhfutgesrgdtreerredtjeenucfhrhhomhepfdftohgsucfnrghnuggvrhhs fdcuoehrohgssegsohhtthhlvggurdgtohguvghsqeenucggtffrrghtthgvrhhnpefgte ejveduueevudfgveefffeuueefudfhieehkefgkeeiudejkeeugeeuffdtfeenucffohhm rghinhephhhtthhprdhonhgvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomheprhhosgessghothhtlhgvugdrtghouggvshdpnhgspghrtghpthht ohepuddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepihhnthgvrhhnrghlsheslh hishhtshdrphhhphdrnhgvth X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 089D9780068; Fri, 7 Mar 2025 04:20:25 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 Date: Fri, 07 Mar 2025 10:20:04 +0100 To: internals@lists.php.net Message-ID: <3a647368-706c-4d67-8dac-9f7d2557da35@app.fastmail.com> In-Reply-To: <779046a0-7c70-45a9-82c4-7c31c502cec2@rwec.co.uk> References: <9964db8c-0ffe-43d5-8246-47fc76b07180@app.fastmail.com> <78a03dd0-fd4a-4f4a-ad8a-37e5704f06fc@app.fastmail.com> <23e162f6-54b0-4564-9d79-7b3bdc3d1ab5@rwec.co.uk> <36cee7e3-2ef8-4f96-a72e-e67a99e5f9bb@rwec.co.uk> <779046a0-7c70-45a9-82c4-7c31c502cec2@rwec.co.uk> Subject: Re: [PHP-DEV] PHP True Async RFC Content-Type: multipart/alternative; boundary=9360546c90e24493a6ea8a363a67463b From: rob@bottled.codes ("Rob Landers") --9360546c90e24493a6ea8a363a67463b Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 6, 2025, at 23:26, Rowan Tommins [IMSoP] wrote: > On 06/03/2025 11:31, Edmond Dantes wrote: > > For example, PHP has functions for working with HTTP. One of them=20 > > writes the last received headers into a "global" variable, and anoth= er=20 > > function allows retrieving them. This is where a context is needed. >=20 >=20 > OK, let's dig into this case: what is the actual problem, and what doe= s=20 > an async design need to provide so that it can be solved. >=20 > As far as I know, all current SAPIs follow one of two patterns: >=20 > 1) The traditional "shared nothing" approach: each request is launched=20 > in a new process or thread, and all global state is isolated to that=20 > request. > 2) The explicit injection approach: the request and response are=20 > represented as objects, and the user must pass those objects around to=20 > where they are needed. >=20 > Notably, 2 can be emulated on top of 1, but not vice versa, and this i= s=20 > exactly what a lot of modern applications and frameworks do: they take=20 > the SAPI's global state, and wrap it in injected objects (e.g. PSR-7=20 > ServerRequestInterface and ServerResponseInterface). >=20 > Code written that way will work fine on a SAPI that spawns a fiber for=20 > each request, so there's no problem for us to solve there. >=20 > At the other extreme are frameworks and applications that access the=20 > global state directly throughout - making heavy use of superglobal,=20 > global, and static variables; directly outputting using echo/print, et= c.=20 > Those will break in a fiber-based SAPI, but as far as I can see, there= 's=20 > nothing the async design can do to fix that. >=20 > In the middle, there are some applications we *might* be able to help:=20 > they rely on global state, but wrap it in global functions or static=20 > methods which could be replaced with some magic from the async=20 > implementation. I think this might be an invalid assumption. A SAPI is written in C (or = at least, using the C api's) and thus can do just about anything. If it = wanted to, it could swap out the global state when switching fibers. Thi= s isn't impossible, nor all that hard to do. If I were writing this feat= ure in an existing SAPI, this is probably exactly what I would do to mai= ntain maximal compatibility. So, at a minimum, I would guess the engine needs to provide hooks that t= he SAPI can use to provide request contexts to the global state (such as= a "(before|after)FiberSwitch" function or something called around the f= iber switch). That being said, I'm unsure if an existing SAPI would send multiple requ= ests to the same thread/process already handling a request. This would b= e a large undertaking and require those hooks to know from which request= output is coming from so it can direct it to the right socket. Remember, fibers are still running in a single thread/process. They are = not threading and running concurrently. They are taking turns in the sam= e thread. Sharing memory between fibers is relatively easy and not compl= icated. Amphp has a fiber-local memory (this context, basically), and I = have never had a use for it, even once, in the last five years. If fibers were to allow true concurrency, we would need many more primit= ives. At the minimum we would need mutexes to prevent race conditions in= critical sections. With current fibers, you don't need to worry about t= hat (usually), because there is never more than one fiber running at any= given time. That being said, I have had to use amphp mutexes and semaph= ores to ensure that there is some kind of synchronization -- a real life= example is a custom database driver I maintain that needs to ensure exa= ctly one fiber is writing a query to the database at a time (since this = is non-blocking). =E2=80=94 Rob --9360546c90e24493a6ea8a363a67463b Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

=
On Thu, Mar 6, 2025, at 23:26, Rowan Tommins [IMSoP] wrot= e:
On 06/03= /2025 11:31, Edmond Dantes wrote:
> For example, PHP ha= s functions for working with HTTP. One of them 
> = writes the last received headers into a "global" variable, and another&n= bsp;
> function allows retrieving them. This is where a= context is needed.


OK, let'= s dig into this case: what is the actual problem, and what does 
an async design need to provide so that it can be solved.

As far as I know, all current SAPIs follow on= e of two patterns:

1) The traditional "shar= ed nothing" approach: each request is launched 
in a = new process or thread, and all global state is isolated to that 
request.
2) The explicit injection approach: t= he request and response are 
represented as objects, = and the user must pass those objects around to 
where= they are needed.

Notably, 2 can be emulate= d on top of 1, but not vice versa, and this is 
exact= ly what a lot of modern applications and frameworks do: they take <= br>
the SAPI's global state, and wrap it in injected objects (= e.g. PSR-7 
ServerRequestInterface and ServerResponse= Interface).

Code written that way will work= fine on a SAPI that spawns a fiber for 
each request= , so there's no problem for us to solve there.

<= div>At the other extreme are frameworks and applications that access the=  
global state directly throughout - making heavy use= of superglobal, 
global, and static variables; direc= tly outputting using echo/print, etc. 
Those will bre= ak in a fiber-based SAPI, but as far as I can see, there's 
nothing the async design can do to fix that.

In the middle, there are some applications we *might* be able t= o help: 
they rely on global state, but wrap it in gl= obal functions or static 
methods which could be repl= aced with some magic from the async 
implementation.<= br>

I think this might be an inval= id assumption. A SAPI is written in C (or at least, using the C api's) a= nd thus can do just about anything. If it wanted to, it could swap out t= he global state when switching fibers. This isn't impossible, nor all th= at hard to do. If I were writing this feature in an existing SAPI, this = is probably exactly what I would do to maintain maximal compatibility.

So, at a minimum, I would guess the engine n= eeds to provide hooks that the SAPI can use to provide request contexts = to the global state (such as a "(before|after)FiberSwitch" function or s= omething called around the fiber switch).

T= hat being said, I'm unsure if an existing SAPI would send multiple reque= sts to the same thread/process already handling a request. This would be= a large undertaking and require those hooks to know from which request = output is coming from so it can direct it to the right socket.
=

Remember, fibers are still running in a single threa= d/process. They are not threading and running concurrently. They are tak= ing turns in the same thread. Sharing memory between fibers is relativel= y easy and not complicated. Amphp has a fiber-local memory (this context= , basically), and I have never had a use for it, even once, in the last = five years.

If fibers were to allow true co= ncurrency, we would need many more primitives. At the minimum we would n= eed mutexes to prevent race conditions in critical sections. With curren= t fibers, you don't need to worry about that (usually), because there is= never more than one fiber running at any given time. That being said, I= have had to use amphp mutexes and semaphores to ensure that there is so= me kind of synchronization -- a real life example is a custom database d= river I maintain that needs to ensure exactly one fiber is writing a que= ry to the database at a time (since this is non-blocking).

=E2=80=94 Rob
--9360546c90e24493a6ea8a363a67463b--