Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126624
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------pccs88E01iOfZgycc1PNGQhS"
Message-ID: <b09dff18-6e2d-4209-91be-f8af08cca8d4@rwec.co.uk>
Date: Fri, 7 Mar 2025 19:07:56 +0000
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Fwd: [PHP-DEV] PHP True Async RFC
To: internals@lists.php.net
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>
 <CAMW7n8DXoKjXaZZ0HsSyA4k_+sY5iRyKhipwsVZvF2Ux+tFnww@mail.gmail.com>
 <CAMW7n8BfpxOV5bd309T-A71mXO=1T8DoaO8c2__oNKUQ1-XrKw@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAMW7n8BfpxOV5bd309T-A71mXO=1T8DoaO8c2__oNKUQ1-XrKw@mail.gmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------pccs88E01iOfZgycc1PNGQhS
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 07/03/2025 08:48, Edmond Dantes wrote:
> There is a B2B CRM built on services. Services are classes 
> instantiated in memory only once via DI, and all that. We process 
> requests. Requests are executed within a logical *Scope*. The scope 
> depends on the *TOKEN* and reflects the following entities:
>
>   * *User Profile*
>   * *Company Settings*
>
> We have two implementation options:
>
>  1. Pass the user profile and company settings to every method.
>  2. Use some static variable to make the semantics shorter.
>

This sounds very much like the same scenario, just different data. The 
key requirement is to partition the data based on the request. 
Interestingly, like the previous example, the scope is not 
per-coroutine, but common to all children of a particular coroutine 
spawned by some SAPI / networking layer - it seems that some way to 
"label" coroutines/fibers might be useful.


> |Async\Context| is designed to *guarantee memory management*, which is 
> a key aspect for *long-running* applications. It *automatically 
> releases object references* when a coroutine completes. The programmer 
> does not need to write *extra code* with |defer()| for this.
>

That is a good point, and a requirement which I didn't think of.

However, the fact that this didn't stand out in the RFC only reinforces 
my key points:

1) Having so many different features in one RFC makes it harder to 
discuss their purpose and design than delivering an overall design 
first, then adding features.

2) The current Async\Context class doesn't have a clear problem 
statement. Even with "guaranteed memory management" as a requirement, we 
could have something much simpler.


> If such primitives are not included in this or future RFCs, and 
> instead are left to chance, *it's better not to accept the RFC at all*.
>

The "or future" in that sentence is key. I'm sorry if I haven't made 
this clear enough, but I am *not* saying that none of these features 
belong in core; I'm not even saying we need to tag a release without 
them. What I'm saying is that they *don't belong in the initial design 
document*, at least not in this level of detail.


> This is the reason why the current RFC is large. It helps to see the 
> bigger picture. Once the general principles are agreed upon, we can 
> split it into parts (Incremental Design).
>

For me, the opposite is true: the size of the RFC is completely 
obscuring the bigger picture, because I "can't see the forest for the 
trees", as the saying goes.

I think it's great that you've thought about how these different pieces 
will interact, but a lot of them can just be sketches of future scope, e.g.

 > It may be useful to have an Async\Context object which can safely 
associate arbitrary data with a particular fiber, to use in place of 
global/static storage. To do this, we need to track the parent-child 
relationship of fibers, and have internal hooks at the start and end of 
a fiber's life to allocate and deallocate the storage. An example of 
what an Async\Context object implementation might look like is [here], 
but the details can be discussed at a later stage.

The fact that the parent-child relationship is valuable is a really 
useful thing to know for the overall design. The fact that you don't 
like using strings as hashmap keys is not.

As someone not well-versed in the terminology and technology of 
concurrency, I find it really hard to see which parts of the RFC are 
far-reaching decisions, and which are just bikeshed colours. As a user, 
I find it really hard to pick out what PHP code I'll actually write to 
make use of this - or even whether I'm the target audience at all, or 
whether this is all likely to be hidden by higher-level libraries.


-- 
Rowan Tommins
[IMSoP]

--------------pccs88E01iOfZgycc1PNGQhS
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 07/03/2025 08:48, Edmond Dantes
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAMW7n8BfpxOV5bd309T-A71mXO=1T8DoaO8c2__oNKUQ1-XrKw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      There is a B2B CRM built on services. Services are classes
      instantiated in memory only once via DI, and all that. We process
      requests. Requests are executed within a logical <strong>Scope</strong>.
      The scope depends on the <strong>TOKEN</strong> and reflects the
      following entities:
      <div dir="ltr">
        <div class="gmail_quote gmail_quote_container">
          <div dir="ltr">
            <div dir="ltr">
              <div>
                <ul>
                  <li><strong>User Profile</strong></li>
                  <li><strong>Company Settings</strong></li>
                </ul>
                <p>We have two implementation options:</p>
                <ol>
                  <li>Pass the user profile and company settings to
                    every method.</li>
                  <li>Use some static variable to make the semantics
                    shorter.</li>
                </ol>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>This sounds very much like the same scenario, just different
      data. The key requirement is to partition the data based on the
      request. Interestingly, like the previous example, the scope is
      not per-coroutine, but common to all children of a particular
      coroutine spawned by some SAPI / networking layer - it seems that
      some way to "label" coroutines/fibers might be useful.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAMW7n8BfpxOV5bd309T-A71mXO=1T8DoaO8c2__oNKUQ1-XrKw@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote gmail_quote_container">
          <div dir="ltr">
            <div dir="ltr">
              <div>
                <p><code>Async\Context</code> is designed to <strong>guarantee
                    memory management</strong>, which is a key aspect
                  for <strong>long-running</strong> applications. It <strong>automatically
                    releases object references</strong> when a coroutine
                  completes. The programmer does not need to write <strong>extra
                    code</strong> with <code>defer()</code> for this.</p>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>That is a good point, and a requirement which I didn't think of.</p>
    <p>However, the fact that this didn't stand out in the RFC only
      reinforces my key points:</p>
    <p>1) Having so many different features in one RFC makes it harder
      to discuss their purpose and design than delivering an overall
      design first, then adding features.<br>
    </p>
    <p>2) The current Async\Context class doesn't have a clear problem
      statement. Even with "guaranteed memory management" as a
      requirement, we could have something much simpler.</p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAMW7n8BfpxOV5bd309T-A71mXO=1T8DoaO8c2__oNKUQ1-XrKw@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote gmail_quote_container">
          <div dir="ltr">
            <div dir="ltr">
              <div>
                <p>
                </p>
                <p>If such primitives are not included in this or future
                  RFCs, and instead are left to chance, <strong>it's
                    better not to accept the RFC at all</strong>.</p>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>The "or future" in that sentence is key. I'm sorry if I haven't
      made this clear enough, but I am *not* saying that none of these
      features belong in core; I'm not even saying we need to tag a
      release without them. What I'm saying is that they *don't belong
      in the initial design document*, at least not in this level of
      detail.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAMW7n8BfpxOV5bd309T-A71mXO=1T8DoaO8c2__oNKUQ1-XrKw@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote gmail_quote_container">
          <div dir="ltr">
            <div dir="ltr">
              <div>
                <p>This is the reason why the current RFC is large. It
                  helps to see the bigger picture. Once the general
                  principles are agreed upon, we can split it into parts
                  (Incremental Design).  <br>
                </p>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>For me, the opposite is true: the size of the RFC is completely
      obscuring the bigger picture, because I "can't see the forest for
      the trees", as the saying goes.</p>
    <p>I think it's great that you've thought about how these different
      pieces will interact, but a lot of them can just be sketches of
      future scope, e.g. </p>
    <p>&gt; It may be useful to have an Async\Context object which can
      safely associate arbitrary data with a particular fiber, to use in
      place of global/static storage. To do this, we need to track the
      parent-child relationship of fibers, and have internal hooks at
      the start and end of a fiber's life to allocate and deallocate the
      storage. An example of what an Async\Context object implementation
      might look like is [here], but the details can be discussed at a
      later stage.</p>
    <p>The fact that the parent-child relationship is valuable is a
      really useful thing to know for the overall design. The fact that
      you don't like using strings as hashmap keys is not.</p>
    <p>As someone not well-versed in the terminology and technology of
      concurrency, I find it really hard to see which parts of the RFC
      are far-reaching decisions, and which are just bikeshed colours.
      As a user, I find it really hard to pick out what PHP code I'll
      actually write to make use of this - or even whether I'm the
      target audience at all, or whether this is all likely to be hidden
      by higher-level libraries.<br>
    </p>
    <p><br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------pccs88E01iOfZgycc1PNGQhS--