Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:126549 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 3AAEF1A00BC for ; Mon, 3 Mar 2025 12:05:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1741003358; bh=lkf+H+w0bX2A2AoBIa7n2qgi46GyGGwPqnchXoHzmuY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=n4UtCNWF9vdSqadcY2wyCEh5isFKE5A0yia2BWxYgGX55A3jaHSakPdg5MPavxaYo jJbEWk9WsxIvJcMUaTc2ML6gyEFHCVJTs13Cl9AopCNydgSrw2EelEJiOytlTR2wO8 1lKBkFWEBVm1bEM2nr6PLfinGRiGLBDPIjm6iVAJjMalKBeAAduG+yNPGT9ZafK/m0 zeYG/mtyRo7V+Gk2+J1Fy8rfbZDUOdkNLYEAYjvKGPH+qECwEV8wSRso2v2VIVpsdt s8r6qS2WmYMzO029QLCx+kLevGHe1xWd0ZkFW5LFIqo/yYoXeQIH9n/I0eH9PxLra8 P4cDNT+yhjQ2g== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 74E38180080 for ; Mon, 3 Mar 2025 12:02:37 +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.0 required=5.0 tests=BAYES_20,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) (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 ; Mon, 3 Mar 2025 12:02:37 +0000 (UTC) Received: by mail-yb1-f170.google.com with SMTP id 3f1490d57ef6-e5dad00b2e6so3480717276.3 for ; Mon, 03 Mar 2025 04:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741003513; x=1741608313; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IOE1GH/YW4ij9IlVx+3q8KpdMiXa+ayRoGOnO0icTys=; b=JqQ53XJMaJet55o+v4Q2XVqW0RGsnxBHyOsgy40Iuvg0bpxQSPmptasvbsgUcT85qP F6j9ZBsFP4Dms/MhAxwEcsOh1b6fVnE2cgCMdub/uKeQ/SsHuJRujnTmoTF39vs6u2q6 vx9WhrV8ZtAx0C8wnxHyXKObY5FWjUxRfzy0EOdTaXigizFNzsfmQw8lP4UjctR+2Vlr zFS3VV/F+GjuRsz/ne5C9G71KUXl/q/lJVppNgSZnb15R8oHmHDjqf9SLiyWN7ODnInB 8QHJydfkCyPHR5hIJWEwIcuReke7DWYShQkff98fXTcdun9DHqzYKB9nB535vpkyf0Zu q+Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741003513; x=1741608313; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IOE1GH/YW4ij9IlVx+3q8KpdMiXa+ayRoGOnO0icTys=; b=SM/Xf3ahB0qkeRf22OnbBs3DZkbYZGdQHhLWHie82uzmrUB9Y0msLf2Assn5uG6/X+ 1reDZkj4JxJ1V0CgPIdt4LJgHvq1DHqe8wayiXLF9dXblDy3SgExgK6PVzcRE3hNNUzS jWRW+Am8z7WLVT39VQYUHynrXy+8t3T5y5A9db2B7qQv5ag1LBBNWg/U6/cSl6WZzkvA gPIIwvi/lU0ntLpzdmvwdc48E7kXNk8N3DARwY0h69CwFbW682MfUysJXWUJsatlCAPS cl0Vmvpur80f/da1x0xguUh2vBDGcpBDC4ZuQV+VXvz0fR0Apr6+AfXPjy1lpSj8+aIi 97Ag== X-Gm-Message-State: AOJu0YxqDFWbZTmDxu48m7uxyJ5DrJdsxq01E/P1vthdejUXDhg+XUJK eq9XYQXIM+IE65OoLg78zY/3Z+jKQ16tOZ27j9dmuJ8Csmm2hZDLmJ5V/axiXWyg1ajSTgeLWv2 ZWv9XcMC+IDL7hMJBn0KDstLR00k= X-Gm-Gg: ASbGncs1aybAu5OHrbgvUwYm1SfPbMNbpSwS2TnXfuX3JyLS70HKnTIqdgYe97MuRf/ ITvfdVcM3dBcFereNLZFJ2bpQrF9U+HPb7P04n5Vz9asi7NES69EmFtSKUaw7Xi98dV3btzLhxa Xq+VykvkOOLuaGO0DOZWMoM90Tew== X-Google-Smtp-Source: AGHT+IEM3Ijqhw0LB71VlSdO9hwuTKVdYibvVCMl2wKO0fdAeW1mmNCOEGIgJNjZB+OUD7HlDu4rtRKaebE9NB9VBiY= X-Received: by 2002:a05:690c:74c9:b0:6f9:a402:ff2e with SMTP id 00721157ae682-6fd4a0130f8mr176722107b3.16.1741003512865; Mon, 03 Mar 2025 04:05:12 -0800 (PST) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 3 Mar 2025 14:05:02 +0200 X-Gm-Features: AQ5f1Jp_RMW-a_hQH0HjzKE-HqcZjgiZJ9sPXa2JCggjgwhcM7bmQc4aYA-oBXI Message-ID: Subject: Re: [PHP-DEV] PHP True Async RFC To: Daniil Gentili Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000efef41062f6ef774" From: edmond.ht@gmail.com (Edmond Dantes) --000000000000efef41062f6ef774 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > As a heavy use of both amphp and go, cancellations (contexts in go) are > absolutely needed, as a fiber may spawn further background fibers in orde= r > to execute some operation, just cancelling that specific fiber will not > cancel the spawned fibers, unless a bunch of boilerplate try-catch blocks > are added to propagate CancellationExceptions. I didn't mean that Cancellation isn't needed at all. I meant that canceling a Fiber is sufficient in most scenarios and leads to clean, understandable code. Other languages have child coroutines (Swoole supports them too), but I'm not sure if that's the right approach. I like context.WithCancel from Go, but it can essentially be implemented directly in PHP land since all the necessary tools are available. A nicer API should use only explicit cancellation objects, as this pattern > of preemptive implicit cancellations The exception mechanism is the standard way to alter the execution flow in PHP. If a programmer writes code with lock and unlock outside of a try-finally block but calls functions between these methods, they are potentially creating a bad solution=E2=80=94at the very least because someo= ne else might later introduce an exception in one of those functions. This is a classic case for languages with exceptions. So far, I haven't found a better way to ensure the logical consistency and integrity of the execution flow. Maybe someone has a suggestion? > The main reason given in the RFC > > The main reason is that PHP has been around for many years and didn=E2=80= =99t just appear yesterday. If you have an idea on how to start the Scheduler implicitly, let's implement it. So far, I have a few ideas: 1. Using an option in php.ini (downside: if PHP is used for multiple projects). 2. Using a CLI option =E2=80=93 so far, I like this the most. A thing I would love to see, on the other hand, is for Context to become a =E2=80=9Cprovider=E2=80=9D It's hard for me to evaluate this idea. Intuitively, it doesn't seem ideal. In general, I'm not very fond of $_GET/$_POST. But on the other hand, why not? This needs some consideration. allow to very easily to turn i.e. php-fpm into a fully asynchronous application server, > where each request is started in the same thread (or in N threads in an M= -N M>N > execution model) but its global state is entirely isolated between fibers= . > > I haven=E2=80=99t thought about this possibility. But wouldn=E2=80=99t th= is break the FCGI contract? Thanks! Ed. > --000000000000efef41062f6ef774 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As a hea= vy use of both amphp and go, cancellations (contexts in go) are absolutely = needed, as a fiber may spawn further background fibers in order to execute = some operation, just cancelling that specific fiber will not cancel the spa= wned fibers, unless a bunch of boilerplate try-catch blocks are added to pr= opagate CancellationExceptions.=C2=A0

I didn&= #39;t mean that Cancellation isn't needed at all. I meant that cancelin= g a Fiber is sufficient in most scenarios and leads to clean, = understandable code.

Other languages have child coroutines (Swoole su= pports them too), but I'm not sure if that's the right approach.

I like context.WithCancel from Go, but it can essentiall= y be implemented directly in PHP land since all the necessary tools are ava= ilable.

A nicer API should use only explicit cancellation objects, as this patte= rn of preemptive implicit cancellations=C2=A0

The exception mechanism is the standard way to alter the execution fl= ow in PHP. If a programmer writes code with lock and unl= ock outside of a try-finally block but calls functions = between these methods, they are potentially creating a bad solution=E2=80= =94at the very least because someone else might later introduce an exceptio= n in one of those functions. This is a classic case for languages with exce= ptions.

So far, I haven't found a better way to ensure the logica= l consistency and integrity of the execution flow. Maybe someone has a sugg= estion?

The main reaso=
n given in the RFC

The main reason is that PHP h= as been around for many years and didn=E2=80=99t just appear yesterday.=C2= =A0

If you have an idea on how to start the Scheduler implicitly, let= 's implement it. So far, I have a few ideas:

  1. =C2= =A0 Using an option in php.ini (downside: if PHP is used for m= ultiple projects).
  2. Using a CLI option =E2=80=93 so far, I like this the most.=C2=A0
<= blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,= 204,204);padding-left:1ex" class=3D"gmail_quote">A thing I would love to se= e, on the other hand, is for Context to become a=C2=A0=E2=80=9Cprovider=E2=80=9D=C2=A0 =C2=A0

It's hard for me to evaluate this idea. Intuit= ively, it doesn't seem ideal. In general, I'm not very fond of $_GET/$_POST. But on the other hand, why not? This ne= eds some=C2=A0 consideration.=C2=A0

allow to very easily to turn i.e. php-fpm =
into a fully asynchronous application server,
where each request is started in the same thread (or in N threads in an M-N=
 M>N
execution model) but its global state is entirely isolated between fibers.<=
/pre>
I haven=E2=80=99t thought about this possibility. But wouldn=E2=80=99t this= break the FCGI contract? =C2=A0

Thanks! Ed.
--000000000000efef41062f6ef774--