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 <internals@lists.php.net>; 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 <internals@lists.php.net>; 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: <rob@bottled.codes>
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 <internals@lists.php.net>; 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 <internals@lists.php.net>; 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: <xms:WrrKZ7m6SRv1__tX3L4igGG_iPrXZTY5D4preKCbep6MYVkWzBcCiQ>
    <xme:WrrKZ-3SqLTpHaQEVZ36zj19_GQuARfXFYM7ZfVAlCFZ6fR35S2r7m9lUY9tu1G-3
    JpyATENN1d4_ChtcaA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduuddtvdekucetufdoteggodetrf
    dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
    pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefogg
    ffhffvkfgjfhfutgesrgdtreerredtjeenucfhrhhomhepfdftohgsucfnrghnuggvrhhs
    fdcuoehrohgssegsohhtthhlvggurdgtohguvghsqeenucggtffrrghtthgvrhhnpefgte
    ejveduueevudfgveefffeuueefudfhieehkefgkeeiudejkeeugeeuffdtfeenucffohhm
    rghinhephhhtthhprdhonhgvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe
    hmrghilhhfrhhomheprhhosgessghothhtlhgvugdrtghouggvshdpnhgspghrtghpthht
    ohepuddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepihhnthgvrhhnrghlsheslh
    hishhtshdrphhhphdrnhgvth
X-ME-Proxy: <xmx:WrrKZxoVP4nWKYsin3ej7nc-w0kjW969MWR2mXpvhftRHm9OqDUhGA>
    <xmx:WrrKZznErGFDeAZjI3Y9vTTjATr_tGqACPu4OkKZxTcch8jVTlsLtg>
    <xmx:WrrKZ52Gql3b9R5dwUuu8mW-chS0ruxBwQkjU1LNLDwWRMiqkv6F6Q>
    <xmx:WrrKZyv7LtYxte2wgn6SblVPUXIz0x0omorkLyNtc-MpGsSxC4pcMg>
    <xmx:WrrKZ2_7SzpJtbtDGBPGHIO51BuiniO473nA9VDhm9QCie5vU7NxdE75>
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: <mailto:internals+help@lists.php.net
list-unsubscribe: <mailto:internals+unsubscribe@lists.php.net>
list-post: <mailto:internals@lists.php.net>
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: 
 <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
 <9964db8c-0ffe-43d5-8246-47fc76b07180@app.fastmail.com>
 <CAMW7n8CM7oBfXCDsKtV4hTFs40UmLCU3183WjYE2exLNqKDWLQ@mail.gmail.com>
 <78a03dd0-fd4a-4f4a-ad8a-37e5704f06fc@app.fastmail.com>
 <CAMW7n8C-Z18MKhyDX2+ofg70cRbwWOk=YWDAZpKtfLZsFVVRng@mail.gmail.com>
 <23e162f6-54b0-4564-9d79-7b3bdc3d1ab5@rwec.co.uk>
 <CAMW7n8A_KM6W0NHk_Ypd2PGdJZbi0quxwGvM27pf-U-YOe-RGw@mail.gmail.com>
 <36cee7e3-2ef8-4f96-a72e-e67a99e5f9bb@rwec.co.uk>
 <CAMW7n8BGbjfCrPeiWO-mucYO3i8x=3XkcULXTjPbP7p3aV7rKg@mail.gmail.com>
 <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

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><div>=
<br></div><div>On Thu, Mar 6, 2025, at 23:26, Rowan Tommins [IMSoP] wrot=
e:<br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>On 06/03=
/2025 11:31, Edmond Dantes wrote:<br></div><div>&gt; For example, PHP ha=
s functions for working with HTTP. One of them&nbsp;<br></div><div>&gt; =
writes the last received headers into a "global" variable, and another&n=
bsp;<br></div><div>&gt; function allows retrieving them. This is where a=
 context is needed.<br></div><div><br></div><div><br></div><div>OK, let'=
s dig into this case: what is the actual problem, and what does&nbsp;<br=
></div><div>an async design need to provide so that it can be solved.<br=
></div><div><br></div><div>As far as I know, all current SAPIs follow on=
e of two patterns:<br></div><div><br></div><div>1) The traditional "shar=
ed nothing" approach: each request is launched&nbsp;<br></div><div>in a =
new process or thread, and all global state is isolated to that&nbsp;<br=
></div><div>request.<br></div><div>2) The explicit injection approach: t=
he request and response are&nbsp;<br></div><div>represented as objects, =
and the user must pass those objects around to&nbsp;<br></div><div>where=
 they are needed.<br></div><div><br></div><div>Notably, 2 can be emulate=
d on top of 1, but not vice versa, and this is&nbsp;<br></div><div>exact=
ly what a lot of modern applications and frameworks do: they take&nbsp;<=
br></div><div>the SAPI's global state, and wrap it in injected objects (=
e.g. PSR-7&nbsp;<br></div><div>ServerRequestInterface and ServerResponse=
Interface).<br></div><div><br></div><div>Code written that way will work=
 fine on a SAPI that spawns a fiber for&nbsp;<br></div><div>each request=
, so there's no problem for us to solve there.<br></div><div><br></div><=
div>At the other extreme are frameworks and applications that access the=
&nbsp;<br></div><div>global state directly throughout - making heavy use=
 of superglobal,&nbsp;<br></div><div>global, and static variables; direc=
tly outputting using echo/print, etc.&nbsp;<br></div><div>Those will bre=
ak in a fiber-based SAPI, but as far as I can see, there's&nbsp;<br></di=
v><div>nothing the async design can do to fix that.<br></div><div><br></=
div><div>In the middle, there are some applications we *might* be able t=
o help:&nbsp;<br></div><div>they rely on global state, but wrap it in gl=
obal functions or static&nbsp;<br></div><div>methods which could be repl=
aced with some magic from the async&nbsp;<br></div><div>implementation.<=
br></div></blockquote><div><br></div><div>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.<b=
r></div><div><br></div><div>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).<br></div><div><br></div><div>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.<br></div>=
<div><br></div><div>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.<br></div><div><br></div><div>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).<br></div><div=
><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></body></html=
>
--9360546c90e24493a6ea8a363a67463b--