Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126674
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------71PHhajYBypAm09EOmzR460i"
Message-ID: <589e1df3-3584-4986-a62a-74cbedb2eb92@rwec.co.uk>
Date: Sun, 9 Mar 2025 12:16:56 +0000
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] PHP True Async RFC
To: internals@lists.php.net
References: <CAMW7n8CM7oBfXCDsKtV4hTFs40UmLCU3183WjYE2exLNqKDWLQ@mail.gmail.com>
 <CAMW7n8C-Z18MKhyDX2+ofg70cRbwWOk=YWDAZpKtfLZsFVVRng@mail.gmail.com>
 <bb7a9f8f-0422-45e5-b4fc-f5757add92b4@app.fastmail.com>
 <CAMW7n8BnzL7d0bd_Y_jGOmyWegKQpm-FzrVFRCcDe=bNFZpi+A@mail.gmail.com>
 <08c8ad0b-e8f4-46e3-99f0-b80748d40b89@app.fastmail.com>
 <07973EAE-2D83-47A8-8FA0-84286C77C02B@rwec.co.uk>
 <48d66433-3ae9-4895-8361-7c81a0a3670d@app.fastmail.com>
 <be7cb263-93a1-4bd8-9416-ae4d3e0bafe6@rwec.co.uk>
 <dbce8889-016a-4c59-864c-d8fdec895adc@app.fastmail.com>
 <CAM0Ccxh=bydoDEHBAV+Gb1_86HJjwhW06kzEsdRiMh93k1F7oA@mail.gmail.com>
 <8599eb8b-d4a3-4cb8-899a-25b134e0d64d@gmail.com>
 <D73BCCC4-3547-45B4-84AD-A5FD6569D43C@rwec.co.uk>
 <74c4c726-63aa-44e0-84c9-840e13a65a4f@gmail.com>
 <77DC5F50-531D-49E8-8BE2-504A19CB5FFD@rwec.co.uk>
 <676e36e4-0b84-4d8c-b3db-2998831cd79d@gmail.com>
 <510B8EF1-9D07-41A8-9EA0-7D99CF7BFC91@rwec.co.uk>
 <bccf099c-55cf-4701-89eb-c26144696eac@gmail.com>
Content-Language: en-GB
In-Reply-To: <bccf099c-55cf-4701-89eb-c26144696eac@gmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------71PHhajYBypAm09EOmzR460i
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 08/03/2025 22:28, Daniil Gentili wrote:
> Even its use is optional, its presence in the language could lead 
> library developers to reduce concurrency in order to allow calls from 
> async blocks, (i.e. don't spawn any background fiber in a method call 
> because it might be called from an async {} block) which is what I 
> meant by crippling async PHP.


I think you've misunderstood what I meant by optional. I meant that 
putting the fiber into the managed context would be optional *at the 
point where the fiber was spawned*.

A library wouldn't need to "avoid spawning background fibers", it would 
simply have the choice between "spawn a fiber that is expected to finish 
within the current managed scope, if any", and "spawn a fiber that I 
promise to manage myself, and please ignore anyone trying to manage it 
for me".

There have been various suggestions of exactly what that could look 
like, e.g. in https://externals.io/message/126537#126625 and 
https://externals.io/message/126537#126630


> The naming of "async {}" is also very misleading, as it does the 
> opposite of making things async, if anything it should be called 
> "wait_all {}"


Yes, "async{}" is a bit of a generic placeholder name; I think Larry was 
the first to use it in an illustration, and we've been discussing 
exactly what it might mean. As we pin down more precise suggestions, we 
can probably come up with clearer names for them.

The tone of your recent e-mails suggests you believe someone is forcing 
this precise keyword into the language, right now, and you urgently need 
to stop it before it's too late. That's not where we are at all, we're 
trying to work out if some such facility would be useful, and what it 
might look like.


It sounds like you think:

1) The language absolutely needs a "spawn detached" operation, i.e. a 
way of starting a new fiber which is queued in the global scheduler, but 
has no automatic relationship to its parent.
2) If the language offered both "spawn managed" and "spawn detached", 
the "detached" mode would be overwhelmingly more common (i.e. users and 
library authors would want to manage the lifecycle of their coroutines 
manually), so the "spawn managed" mode isn't worth implementing.

Would that be a fair summary of your opinion?

-- 
Rowan Tommins
[IMSoP]

--------------71PHhajYBypAm09EOmzR460i
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 08/03/2025 22:28, Daniil Gentili
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:bccf099c-55cf-4701-89eb-c26144696eac@gmail.com">Even its
      use is optional, its presence in the language could lead library
      developers to reduce concurrency in order to allow calls from
      async blocks, (i.e. don't spawn any background fiber in a method
      call because it might be called from an async {} block) which is
      what I meant by crippling async PHP.</blockquote>
    <p><br>
    </p>
    <p>I think you've misunderstood what I meant by optional. I meant
      that putting the fiber into the managed context would be optional
      *at the point where the fiber was spawned*. </p>
    <p>A library wouldn't need to "avoid spawning background fibers", it
      would simply have the choice between "spawn a fiber that is
      expected to finish within the current managed scope, if any", and
      "spawn a fiber that I promise to manage myself, and please ignore
      anyone trying to manage it for me".</p>
    <p>There have been various suggestions of exactly what that could
      look like, e.g. in <a class="moz-txt-link-freetext" href="https://externals.io/message/126537#126625">https://externals.io/message/126537#126625</a> and
      <a class="moz-txt-link-freetext" href="https://externals.io/message/126537#126630">https://externals.io/message/126537#126630</a><br>
    </p>
    <p><br>
    </p>
    <p>
      <blockquote type="cite"><span dir="ltr"
          style="margin-top:0; margin-bottom:0;">The naming of "async
          {}" is also very misleading, as it does the opposite of making
          things async, if anything it should be called "wait_all {}"</span></blockquote>
    </p>
    <p><br>
    </p>
    <p>Yes, "async{}" is a bit of a generic placeholder name; I think
      Larry was the first to use it in an illustration, and we've been
      discussing exactly what it might mean. As we pin down more precise
      suggestions, we can probably come up with clearer names for them.<br>
    </p>
    <p>The tone of your recent e-mails suggests you believe someone is
      forcing this precise keyword into the language, right now, and you
      urgently need to stop it before it's too late. That's not where we
      are at all, we're trying to work out if some such facility would
      be useful, and what it might look like.</p>
    <p><br>
    </p>
    <p>It sounds like you think:</p>
    <p>1) The language absolutely needs a "spawn detached" operation,
      i.e. a way of starting a new fiber which is queued in the global
      scheduler, but has no automatic relationship to its parent.<br>
      2) If the language offered both "spawn managed" and "spawn
      detached", the "detached" mode would be overwhelmingly more common
      (i.e. users and library authors would want to manage the lifecycle
      of their coroutines manually), so the "spawn managed" mode isn't
      worth implementing. </p>
    <p>Would that be a fair summary of your opinion?<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------71PHhajYBypAm09EOmzR460i--