Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:126658 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 2058F1A00BC for ; Sat, 8 Mar 2025 20:22:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1741465216; bh=m1gTIs3i8x9fDRvnH/DLw6iYJjpK2NI6t8QkocLdv4c=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=hzLIifcKHZneWjOHkOTfEF31TnAe5vLk6sYD1jMUNt0erALLHxkMqpbX3pEVUh/+W up1C9zHrwJTYyuuIGilVLvAxf9ViVY8PKINBvd6sit8biq6Di/T4HAiVJ42e+NfjQX 12BJvGArkoI/LZPyhRom0W2lxy0Mgyf8mi825nr3A3i/ktdvslRGrVO3Vuq2hto/KL BxtOlDgHcvAP9t8MxY90ISnp8xCJy3i5cwLBSx4Zgm4nz0Y97CP1J9/eN+kCFEyyCm k9bcVqQf/d0Kw299OhOs13uXpf0xyet+btVf3zb+2p70jIprLkZRX5OEJACA9Psbg6 8T5XQuYLJ9ZRA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id F2FD918005B for ; Sat, 8 Mar 2025 20:20:15 +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.5 required=5.0 tests=BAYES_05,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-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) (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 20:20:15 +0000 (UTC) Received: by mail-yb1-f182.google.com with SMTP id 3f1490d57ef6-e53ef7462b6so2553467276.3 for ; Sat, 08 Mar 2025 12:22:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741465370; x=1742070170; 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=IoVl/6mgNJNMIQlIG3i+OmAOji256u6XCSjCr1t9Q6c=; b=WRilbAq6WPgeajg/O6pybZ4TKWq+KSRXCHyBuoPcOAv97/+BaHXibVbXBcvGWUytEB Cq6VYnpDS7eejV7JoR4Vgbvrj0zup+jjTGEcu5hstwMM7YOnh0l7DVFxZxjTBG+evf9T MxLHcLUtA1fRFZq3PfsIrJ1yuBvqV+/ivZQWb/zmZJomJkK5lsIRR4LTJma9JWS4vAaI CNZyVQ4MuT1fAPHq4y9m6elOlesU8WId6sPi3y3XBqmXBi6YGno+3KmH0JJRf/4Ffnp0 vAouh3kJhpDAM9g0uynx1D9v/BQvgpeoEusshzs77Nsvt2CelC4hJZc4CKmv+3qmAVVY O8fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741465370; x=1742070170; 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=IoVl/6mgNJNMIQlIG3i+OmAOji256u6XCSjCr1t9Q6c=; b=Y+ZhkmM75b94qF3aLZlJL/CGQRCGxmGuLBuVxPKriBlQqqutxNNSiJUX8wfvklvdX6 /ogxbR1u0GvOqHamNPUmQJ95w3c+Det0/J1AoZ/AcKysquo+XVNxC45f3IeJMeceLmvd eZbziitAr+K2BA3p6IYKUzRhA6pGfmL+uVbbxmNszRN0dJRH3r4vpMswWLvtawI1yszJ RfNpYlS1lokP+pQ+RQCFX+ey3bUEo6WExPs6U+PNC7qOZreMF8W2x1o0BdApoMgyM7sj aGfiSj2C/EIu6217JtaXtCjYEovgsN1WH2POCvxPwNaMtYilC+2QcQDhdRzmH5tfmd1f wboQ== X-Gm-Message-State: AOJu0Yx+GXV2buQikcwNK0HpckVNgovwjpu/vartDplE+IC7/bRlOloF Fw/4n+LaqVMpaZ3zJPYoAmr8C8Vp+Ld1dVYx+Opzp9gpVm6lGLol7zOoIu9eFMOo+qlunXA/vc3 +LyYlgkj16B1Cyk7LnyHjWwnA+R5LzfHszTM= X-Gm-Gg: ASbGncsojyQmyaCuVDnXJGpratVkmXjiovTjADf4V+SRRVx/cvv9ppprPAc+5Mj+4Nf W0EgBaUNKWEeA/ea7VTme/FUpHRgqOoo1rv+Nkwp06WC3V0AAtxXcMG42+I7CMq6E0rpaluBagZ 7H7940ghcmz2z7yOlSXi0EIXxvnA== X-Google-Smtp-Source: AGHT+IGZT8hlfjp8rylszZ9d99HyS5Ux9eybDEnWqe9eapx5olC+iHsXpUto4gSm+oQJamxwc0ESPEQC3PlXr565Mrs= X-Received: by 2002:a05:6902:1886:b0:e5d:b88a:5536 with SMTP id 3f1490d57ef6-e635c1f9fb3mr10016786276.44.1741465369862; Sat, 08 Mar 2025 12:22:49 -0800 (PST) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <1b6a5b3b-be9b-4e46-9cc6-b8b7f57b8494@app.fastmail.com> In-Reply-To: <1b6a5b3b-be9b-4e46-9cc6-b8b7f57b8494@app.fastmail.com> Date: Sat, 8 Mar 2025 22:22:39 +0200 X-Gm-Features: AQ5f1Jpq2XaR0FjkWkUOrU1K-pvoDFK0GVuB3sYRBCog7LYcccDmBgzn2QLpP90 Message-ID: Subject: Re: [PHP-DEV] Re: PHP True Async RFC To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="000000000000c26a68062fda80a7" From: edmond.ht@gmail.com (Edmond Dantes) --000000000000c26a68062fda80a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > This is incorrect. "Create an async bounded context playpen" (what I called "async" in my example) > and "start a fiber/thread/task" (what I called "spawn") are two *separate* operations, and > must remain so. > > So, you use *async* to denote the context and *spawn* to create a coroutine= . Regarding the context, it seems there's some confusion with this term. Let's try to separate it somehow. For coroutines to work, a *Scheduler* must be started. There can be only one *Scheduler* per OS thread. That means creating a new async task *does not* create a new *Scheduler*. Apparently, *async {}* in the examples above is the entry point for the *Scheduler*. > > This is probably not the ideal way to structure it in practice, but it should get the point across. > Sounds like a perfect solution. However, the initialization order raises some doubts: it seems that all required coroutines must be created in advance. Will this be convenient? What if a service doesn=E2=80=99t want to initialize a coroutine immediatel= y? What if it=E2=80=99s not loaded into memory right away? *Lazy load.* For example, we have a *Logger* service, which usually starts a coroutine for log flushing. Or even multiple coroutines (e.g., a timer as well). But the service itself might not be initialized and could start only on first use. Should we forbid this practice? If you want to be a service, should you *always* initialize yourself upfront? Wait a minute. This resembles how an OS works. At *level 0*, the operating system runs, while user-level code interacts with it via *interrupts*. It's almost the same as *opening a channel in the ROOT context* and sending a message through the channel from some *child context*. Instead of sending a message directly to the Logger, we could send it to the *service manager* through a channel. Since the *channel was opened in the ROOT context*, all operations would also execute in the *ROOT context*. And if the LOGGER was not initialized, it would be initialized *from the ROOT context*. Possible drawbacks: 1. It's unclear how complex this would be to implement. 2. If messages are sent via a channel, the logger *won't be able to fetch additional data from the request environment*. All data must be explicitly passed, or the *entire context* must be thrown into the channel. Needs more thought. But in any case, the idea with the channel is good. It can cover many scenarios. Everything else is correct, I don=E2=80=99t have much to add. --- Ed. --000000000000c26a68062fda80a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>
>=C2=A0This is incorrect. "Create an async bounded context pla= ypen" (what I called=C2=A0"async" in my example)
> and "start = a fiber/thread/task" (what I called=C2=A0"spawn") are two *separate* opera= tions, and > must remain so.
>
>

So, you use async to denote the context = and spawn to create a coroutine.

Regarding the context, it seems there's some confusion with this ter= m. Let's try to separate it somehow.

For coroutines to work, a Scheduler must be started. Th= ere can be only one Scheduler per OS thread. That means cr= eating a new async task does not create a new Sche= duler.

Apparently, async {} in the examples above is the entry= point for the Scheduler.

>=C2=A0
>=C2=A0This is probably not th= e ideal way to structure it in practice, but it should get the=C2=A0= point across.= =C2=A0
>

Sounds like a perfect solution.

However,= the initialization order raises some doubts: it seems that all required co= routines must be created in advance. Will this be convenient? What if a ser= vice doesn=E2=80=99t want to initialize a coroutine immediately? What if it= =E2=80=99s not loaded into memory right away? Lazy load.

For example, we have a Logger service, which usually = starts a coroutine for log flushing. Or even multiple coroutines (e.g., a t= imer as well). But the service itself might not be initialized and could st= art only on first use.

Should we forbid this practice?
If you want to be a service, should you always initialize = yourself upfront?

Wait a minute. This resembles how an OS works. At <= strong>level 0, the operating system runs, while user-level code i= nteracts with it via interrupts.

It's almost the= same as opening a channel in the ROOT context and sending= a message through the channel from some child context. In= stead of sending a message directly to the Logger, we could se= nd it to the service manager through a channel.

Sinc= e the channel was opened in the ROOT context, all operatio= ns would also execute in the ROOT context. And if the LOGGER was not initialized, it would be initialized from t= he ROOT context.

Possible drawbacks:

  1. It's unclear how complex this would be to implement.
  2. If messages are sent via a channel, the logger won't be abl= e to fetch additional data from the request environment. All data = must be explicitly passed, or the entire context must be t= hrown into the channel.=C2=A0

Needs more thought.

But in any case, the idea with the channel= is good. It can cover many scenarios.

Everything else is correct, I don=E2=80=99t have much to add.

= ---

Ed.

--000000000000c26a68062fda80a7--