[PHP-DEV] PHP 8.4.7RC2 available for testing

Hi all! Since RC1 had a regression bug, we have prepared RC2 with some changes reverted. PHP 8.4.7RC2 has just been released and may be downloaded from https://downloads.php.net/~saki/ Or use the git tag: php-8.4.7RC2 Windows binaries are available at: https://windows.php.net/qa/ Please test i

[PHP-DEV] PHP 8.3.21RC1 available for testing

PHP 8.3.21RC1 has just been released and can be downloaded from: https://downloads.php.net/~eric/ or https://qa.php.net/ or use the git tag: php-8.3.21RC1 Windows binaries are available at: https://windows.php.net/qa/#php-8.3 Please test it carefully, and report any bugs to https://github.c

[PHP-DEV] PHP 8.4.7RC1 available for testing

Hi all! PHP 8.4.7RC1 has just been released and may be downloaded from https://downloads.php.net/~saki/ Or use the git tag: php-8.4.7RC1 Windows binaries are available at: https://windows.php.net/qa/ Please test it carefully, and report any bugs at https://github.com/php/php-src/issues 8.4.7

Re: [PHP-DEV] PHP True Async RFC Stage 3

Hi Edmond! On Wed, Apr 16, 2025 at 7:02 AM Edmond Dantes wrote: > Good day, everyone. I hope you're doing well. > > I’d like to introduce the RFC for the True Async component. > > https://wiki.php.net/rfc/true_async > > This time the work took longer because I was exploring different > architect

Re: [PHP-DEV] PHP True Async RFC Stage 3

Good day, Deleu! > What happens if the coroutine didn't finish execution? does `disposeSafely()` means that it will wait until completion to safely clear it up or does it mean it will attempt to dispose and throw an exception if it fails to do so? Cooperative cancellation implies that a coroutine

Re: [PHP-DEV] PHP True Async RFC Stage 3

Hello, Rowan! > I don't have time to dig into the details of this draft at the moment, but will say that a vote in two weeks is not at all realistic. I just used the Flow from the Wiki. :) > My only other comment at a very quick glance is that I see the Context section is still included, and stil

Re: [PHP-DEV] PHP True Async RFC Stage 3

On 17 April 2025 09:54:26 BST, Edmond Dantes wrote: >> My only other comment at a very quick glance is that I see the Context >section is still included, and still has most of its complexity. >Almost every section of the RFC has a "Motivation" subsection, which >explains why a particular tool i

Re: [PHP-DEV] PHP True Async RFC Stage 3

Hello, Vincent. > The `spawn` keyword might disqualify this rfc, i talked to alot of php devs about this rfc and they all had a similar complaint about the keyword, maybe a keyword choice poll might help when the rfc voting goes live. To have any kind of vote, we need multiple options. The keywor

Re: [PHP-DEV] PHP True Async RFC Stage 3

Here are list of the problems i saw in this RFC: 1.) The `spawn` keyword might disqualify this rfc, i talked to alot of php devs about this rfc and they all had a similar complaint about the keyword, maybe a keyword choice poll might help when the rfc voting goes live. 2.) This whole rfc seem a l

Re: [PHP-DEV] PHP True Async RFC Stage 3

> The link in Patches and Tests is currently giving a 404 Not Found. > Can you update the link to your proof of concept implementation? Thank you for pointing that out. I’ve corrected the link. https://github.com/EdmondDantes/php-src/tree/async/ext/async

Re: [PHP-DEV] PHP True Async RFC Stage 3

The link in Patches and Tests is currently giving a 404 Not Found. Can you update the link to your proof of concept implementation?

Re: [PHP-DEV] PHP True Async RFC Stage 3

On 16 April 2025 10:59:25 BST, Edmond Dantes wrote: >Good day, everyone. I hope you're doing well. > >I’d like to introduce the RFC for the True Async component. > >https://wiki.php.net/rfc/true_async > > This RFC will go to a vote in about two weeks. Hi Ed, I don't have time to dig into the

Re: [PHP-DEV] PHP True Async RFC Stage 3

is "True Async" a fancy way of saying multithreading? Seems like a threading api to me

[PHP-DEV] PHP True Async RFC Stage 3

Good day, everyone. I hope you're doing well. I’d like to introduce the RFC for the True Async component. https://wiki.php.net/rfc/true_async This time the work took longer because I was exploring different architectural options and paid more attention to how it works in other languages. I was

[PHP-DEV] PHP 8.4.6 Released

The PHP development team announces the immediate availability of PHP 8.4.6. This is a bugfix release. All PHP 8.4 users are encouraged to upgrade to this version. For source downloads of PHP 8.4.6 please visit our downloads page. Windows binaries can be found on the PHP for Windows site. The list

[PHP-DEV] PHP 8.3.20 Released

The PHP development team announces the immediate availability of PHP 8.3.20. This is a bugfix release. All PHP 8.3 users are encouraged to upgrade to this version. For source downloads of PHP 8.3.20 please visit our downloads page: https://www.php.net/downloads Windows source and binaries can be

Re: [PHP-DEV] PHP True Async RFC - Stage 2

Continuing the discussion from [[PHP-DEV] PHP True Async RFC - Stage 2]( https://discourse.thephp.foundation/t/php-dev-php-true-async-rfc-stage-2/1573/16 ): [quote="Crell, post:16, topic:1573"] // Creates an async scope, in which you can create coroutines. [/quote] Yes, I understand wh

Re: [PHP-DEV] PHP True Async RFC - Stage 2

> > "Cheating" in the sense that you wrote out a "general syntax", > I got it. > That's not the problem; the problem is that the following are all equivalent expressions: > (((foo( In principle, this is not a problem because the expression in parentheses preceded by `spawn` is unambiguously

Re: [PHP-DEV] PHP True Async RFC - Stage 2

Oops, I made a mistake in the logic of `Scope` and coroutines. According to the RFC, the following code behaves differently: ```php currentScope()->spawn ... // This coroutine belongs to the Scope spawn ... // This one is a child coroutine ``` I was sure that I had checked all the major edge cas

Re: [PHP-DEV] PHP True Async RFC - Stage 2

On 19 March 2025 15:51:38 GMT, Edmond Dantes wrote: >> >> "Cheating" in the sense that you wrote out a "general syntax", >> >I got it. > >> That's not the problem; the problem is that the following are all >equivalent expressions: >> (((foo( > >In principle, this is not a problem because

[PHP-DEV] PHP 8.3.20RC1 Ready for testing

PHP 8.3.20RC1 has just been released and can be downloaded from: https://downloads.php.net/~jakub/ or https://qa.php.net/ or use the git tag: php-8.3.20RC1 Windows binaries are available at: https://windows.php.net/qa/#php-8.3 Please test it carefully, and report any bugs to https://github.co

[PHP-DEV] PHP 8.4.6RC1 Ready for testing

PHP 8.4.6RC1 has just been released and may be downloaded from https://downloads.php.net/~calvinb/ Or use the git tag: php-8.4.6RC1 Windows binaries are available at: https://windows.php.net/qa/ Please test it carefully, and report any bugs at https://github.com/php/php-src/issues 8.4.6 should

Re: [PHP-DEV] PHP True Async RFC - Stage 2

> At the language abstraction level, we can say that spawn performs a single operation: it creates an execution context. In this case, the *execution context* is a low-level term that refers to the combination of processor register states and the call stack (as well as the state of the Zend engine)

Re: [PHP-DEV] PHP True Async RFC - Stage 2

> > You're cheating again - you've put an extra pair of brackets around one > expression and not the other, and assumed they'll work differently, but that's > not the grammar you proposed. > Why am I cheating? > spawn (getClosure()); This is an honest statement, provided that the second parenthese

Re: [PHP-DEV] PHP True Async RFC - Stage 2

Hello. > > So as an outline, I would recommend: > Yes, your suggestion is interesting. I'll think about that section next week. However, I can say that I’ve already dropped the “philosophy” section. I decided to move it into a separate article that will be available as an artifact. Such articles

Re: [PHP-DEV] PHP True Async RFC - Stage 2

> > You already explicitly await all fibers spawned in the generateReport function, you get all the data you need, any extra spawned fibers should not interest you for the purpose of the logic of generateReport. > In this specific code, it only awaits the tasks it has launched itself. So, if anot

Re: [PHP-DEV] PHP True Async RFC - Stage 2

> > As I write more code examples, I'm starting to get annoyed by the verbosity > of the `spawn in $scope` construct—especially in situations where all spawns > need to happen within the same context. > > At the same time, in 80% of cases, it turns out that explicitly defining > `$scope` is th

Re: [PHP-DEV] PHP True Async RFC - Stage 2

> > Again, that's the *how*, not the *why*. We only need to "get rid of" the parentheses if there's some reason to type them in the first place. > I’ve already understood that. You mean it’s not the reason, but one of the possible solutions. But it’s one of the solutions that, from my point of vie

Re: [PHP-DEV] PHP True Async RFC - Stage 2

On 20/03/2025 11:01, Edmond Dantes wrote: > > > > Specifically, what is the use case where syntax #2, "spawn function_call" is not good enough, leading us to add a special case into the grammar. > > > Additional parentheses around + parentheses after. That is, (closure)(). The goal is to get r

Re: [PHP-DEV] PHP True Async RFC - Stage 2

> > Nitpick to make sure we're talking about the same thing: What does "Separate execution context" mean here? Because a keyword whose description includes "and" is always a yellow flag at least. > At the language abstraction level, we can say that spawn performs a single operation: it creates a

Re: [PHP-DEV] PHP True Async RFC - Stage 2

>> >> This example highlights one of the concerns I have with fibers and this approach in general. That example will still execute synchronously, taking file_get_contents() * 3, even though it is in a coroutine function. >> >Is that really a problem? If a programmer wrote the code `$x = 1 / 0`, t

Re: [PHP-DEV] PHP True Async RFC - Stage 2

On Thu, Mar 20, 2025, at 2:06 AM, Edmond Dantes wrote: > This is simply a wonderful explanation. I will be able to go through each > point. > > But before that, let's recall what spawn essentially is. > Spawn is an operation that creates a separate execution context and > then calls a function

Re: [PHP-DEV] PHP True Async RFC - Stage 2

> > This example highlights one of the concerns I have with fibers and this approach in general. That example will still execute synchronously, taking file_get_contents() * 3, even though it is in a coroutine function. > Is that really a problem? If a programmer wrote the code `$x = 1 / 0`, then

Re: [PHP-DEV] PHP True Async RFC - Stage 2

On Thu, Mar 20, 2025, at 12:01, Edmond Dantes wrote: > ```php > spawn fn() => [file_get_content(), file_get_content(), file_get_content()] > ``` This example highlights one of the concerns I have with fibers and this approach in general. That example will still execute synchronously, taking fi

Re: [PHP-DEV] PHP True Async RFC - Stage 2

> In terms of the grammar, it is a special case of #1 yes. > This example maybe helps explain why this might be surprising: > spawn $action; Aha, so if I can write `spawn closure`, why can't I do the same with a variable? Yes, this creates an inconsistency. that's to be expected since the parent

Re: [PHP-DEV] PHP True Async RFC - Stage 2

On 20 March 2025 07:06:16 GMT, Edmond Dantes wrote: I forgot to include some relevant text to quote, but I absolutely agree that syntax #2 should be our default. I think the only thing I'm still unsure of is whether we need anything else on top of it, and if so what. > >> 4: keyword in

Re: [PHP-DEV] PHP True Async RFC - Stage 2

This is simply a wonderful explanation. I will be able to go through each point. But before that, let's recall what spawn essentially is. Spawn is an operation that creates a separate execution context and then calls a function within it. To perform this, spawn requires two things: 1. **callable**

Re: [PHP-DEV] PHP True Async RFC - Stage 2

First, side note: When I said "Tim" in my earlier messages, I was in fact referring to Rowan. I do not know why I confused Tim and Rowan. My apologies to both Tim and Rowan for the confusion. On Tue, Mar 18, 2025, at 2:26 AM, Edmond Dantes wrote: > Hello, Larry. > >> >> First off, it desperate

Re: [PHP-DEV] PHP True Async RFC - Stage 2

On 19/03/2025 19:24, Edmond Dantes wrote: > Yes, that would probably be a bad choice as well. Which is why I've repeatedly suggested a different keyword, and AFAIK you still haven't actually voiced an opinion on that. Does this concern the syntax of `spawn block {}` or did I miss something?

Re: [PHP-DEV] PHP True Async RFC - Stage 2

> > But even though we're talking in circles about why, > your latest examples do avoid the particular problem I was trying to describe. > I thought the problem was that the syntax wouldn't work. Is there any other issue? > > Yes, that would probably be a bad choice as well. Which is why I've rep

Re: [PHP-DEV] PHP True Async RFC - Stage 2

> > When even the official language documentation is telling you in ALL CAPS to not use something, you automatically know it’s a major footgun which has already been abused by newbies. > This is a compelling example of why you should not use the await currentScope() construct. Thank you. >

Re: [PHP-DEV] PHP True Async RFC - Stage 2

> > Please, don't use word operator in this context. It's a keyword, > statement or language construct, but not operator. It's important > especially when you write an RFC. > Thank you so much for paying attention to this!

Re: [PHP-DEV] PHP True Async RFC - Stage 2

On 19 March 2025 11:27:11 GMT, Edmond Dantes wrote: >> >> You're cheating again - you've put an extra pair of brackets around one >> expression and not the other, and assumed they'll work differently, but >that's >> not the grammar you proposed. >> > >Why am I cheating? "Cheating" in the sense

Re: [PHP-DEV] PHP True Async RFC - Stage 2

On 19.03.2025 12:51, Edmond Dantes wrote: > > or other weird shenanigans? I think it would be better as a statement. > Your example was absolutely convincing. I have nothing to argue with :) So, `suspend` is 100% an operator. Please, don't use word operator in this context. It's a keyword,

Re: [PHP-DEV] PHP True Async RFC - Stage 2

> > Generally, RFCs are for changes in the language itself, not for API contracts in C. That can generally be handled in PRs, if I understand correctly. > I thought this was handled by PHP INTERNAL. So I have no idea how it actually works. > > or other weird shenanigans? I think it would be bet

Re: [PHP-DEV] PHP True Async RFC - Stage 2

> > P.S. + 1 example: > > > declare(strict_types=1); > > use Async\Scope; > use function Async\currentScope; > > function fetchUrl(string $url): string { > $ctx = stream_context_create(['http' => ['timeout' => 5]]); > return file_get_contents($url, false, $ctx); > } > > function fetc

Re: [PHP-DEV] PHP True Async RFC - Stage 2

On 19 March 2025 07:07:36 GMT, Edmond Dantes wrote: >Continuing the discussion from [[PHP-DEV] PHP True Async RFC - Stage 2]( >https://discourse.thephp.foundation/t/php-dev-php-true-async-rfc-stage-2/1573/24 >): > >[quote="Rowan_Tommins_IMSoP, post:24, topic:1573"] J

Re: [PHP-DEV] PHP True Async RFC - Stage 2

Continuing the discussion from [[PHP-DEV] PHP True Async RFC - Stage 2]( https://discourse.thephp.foundation/t/php-dev-php-true-async-rfc-stage-2/1573/24 ): [quote="Rowan_Tommins_IMSoP, post:24, topic:1573"] I'm still confused why you started talking about how to implement "de

Re: [PHP-DEV] PHP True Async RFC - Stage 2

On Sun, Mar 16, 2025, at 10:24, Edmond Dantes wrote: > Good day, everyone. I hope you're doing well. > > https://wiki.php.net/rfc/true_async > > Here is a new version of the RFC dedicated to asynchrony. > > Key differences from the previous version: > > * The RFC is not based on Fiber; it int

Re: [PHP-DEV] PHP True Async RFC - Stage 2

On 18 March 2025 08:22:18 GMT, Edmond Dantes wrote: spawning in a scope a "second-class citizen" if `spawn foo($bar);` Reminds me of *"post-purchase rationalization"* or the *"IKEA effect".* when effort has already been invested into something, and then suddenly, there's a more convenient

Re: [PHP-DEV] PHP True Async RFC - Stage 2

On Tue, Mar 18, 2025, at 8:45 AM, Talysson Lima wrote: > If I say it's bright, you call it dark. > If I choose the east, you push for the south. > You’re not seeking a path, just a fight... > Debating with you? Not worth the time! Please do not top post. --Larry Garfield

Re: [PHP-DEV] PHP True Async RFC - Stage 2

If I say it's bright, you call it dark. If I choose the east, you push for the south. You’re not seeking a path, just a fight... Debating with you? Not worth the time! Em ter., 18 de mar. de 2025 às 03:00, Larry Garfield escreveu: > On Sun, Mar 16, 2025, at 4:24 AM, Edmond Dantes wrote: > > Good

Re: [PHP-DEV] PHP True Async RFC - Stage 2

> > spawning in a scope a "second-class citizen" if `spawn foo($bar);` > Reminds me of *"post-purchase rationalization"* or the *"IKEA effect".* when effort has already been invested into something, and then suddenly, there's a more convenient way. And that convenient way seems to devalue the fi

Re: [PHP-DEV] PHP True Async RFC - Stage 2

On 18 March 2025 05:59:07 GMT, Larry Garfield wrote: >My biggest issue, though, is that I honestly can't tell what the mental model >is supposed to be. The RFC goes into detail about three different async >models. Are those standard terms you're borrowing from elsewhere, or your own >crea

Re: [PHP-DEV] PHP True Async RFC - Stage 2

Hello, Larry. > > First off, it desperately needs an "executive summary" section up at the top. > There's a *lot* going on, and having a big-picture overview would help a ton. (For > examples, see property hooks[1] and pattern matching[2].) > I looked at the examples you provided, but I still don

Re: [PHP-DEV] PHP True Async RFC - Stage 2

On Sun, Mar 16, 2025, at 4:24 AM, Edmond Dantes wrote: > Good day, everyone. I hope you're doing well. > > https://wiki.php.net/rfc/true_async > > Here is a new version of the RFC dedicated to asynchrony. > > Key differences from the previous version: > > * The RFC is not based on Fiber; it introdu

Re: [PHP-DEV] PHP True Async RFC - Stage 2

On 17/03/2025 07:58, Edmond Dantes wrote: However, I really liked the `$scope->spawn()` construct in the example code, as it feels the most natural compared to `spawn in`. Moreover, the `spawn in` expression is quite complex to implement, but I don't have enough experience to evaluate it prope

Re: [PHP-DEV] PHP True Async RFC - Stage 2

# BoundedScope I tried to refine the `BoundedScope` class to its logical completeness, considering your feedback. However, I no longer like it because it now resembles an advanced `ComposeFuture` or `BoundedFuture` (I'm not even sure which one). There is no doubt that such functionality is needed

Re: [PHP-DEV] PHP True Async RFC - Stage 2

Hello. In this email, I will focus only on the syntax because it is a separate and rather complex topic. First, the RFC does not clearly describe the syntax, which needs to be fixed. Second, you are right that methods and operators cause confusion. However, I really liked the `$scope->spawn()` co

Re: [PHP-DEV] PHP True Async RFC - Stage 2

Hello, Vincent. > > Personally, i love the formal RFC for it's low level accessibility and this new RFC isn't that bad. > If you mean classes like SocketHandle and so on, then the low-level API can be available as a separate extension. > > The `spawn` keyword maybe the right keyword to use but

Re: [PHP-DEV] PHP True Async RFC - Stage 2

On 16/03/2025 09:24, Edmond Dantes wrote: Good day, everyone. I hope you're doing well. https://wiki.php.net/rfc/true_async Here is a new version of the RFC dedicated to asynchrony. I would like to once again thank everyone who participated in the previous discussion. It was great! Thank

Re: [PHP-DEV] PHP True Async RFC - Stage 2

Edmond, I program microcontrollers. I have a "main loop" and "interruption loops" which are not part of the "main loop" since they are dependent on some event like a button push (for example) and they are dependent on random user input. So for the wording I would use the word 'aside' because it is

Re: [PHP-DEV] PHP True Async RFC - Stage 2

> What is this? I mean structured concurrency: https://wiki.php.net/rfc/true_async#structured_concurrency

Re: [PHP-DEV] PHP True Async RFC - Stage 2

What is this? On Sun, Mar 16, 2025 at 9:30 PM Edmond Dantes wrote: > > Spawning a child thread means you don't care about if it will ever > finish. > > In the context of this RFC, the parent limits the execution time of child > coroutines. Does this mean that the verb *spawn* is not the best ch

Re: [PHP-DEV] PHP True Async RFC - Stage 2

> Spawning a child thread means you don't care about if it will ever finish. In the context of this RFC, the parent limits the execution time of child coroutines. Does this mean that the verb *spawn* is not the best choice?

Re: [PHP-DEV] PHP True Async RFC - Stage 2

Edmond, async stuff is like having another thread. So "spawn" fits but also "throw" in terms of what it does. At least what it actually does (at least what it must) at a low level. > The `spawn` keyword maybe the right keyword to use but it seems more weird, can we find another keyword to use oth

Re: [PHP-DEV] PHP True Async RFC - Stage 2

Just in case, I'll state this explicitly. The current RFC does not remove features from the previous version; rather, it represents its high-level part, with structural concurrency added. It has been reduced in size, making it easier to discuss. >From an implementation perspective, it seems that a

Re: [PHP-DEV] PHP True Async RFC - Stage 2

Personally, i love the formal RFC for it's low level accessibility and this new RFC isn't that bad. The `spawn` keyword maybe the right keyword to use but it seems more weird, can we find another keyword to use other than that? Most languages i've seen make use of only the `async/await` keyword.

Re: [PHP-DEV] PHP True Async RFC - Stage 2

Hello. > > Just one quick question for now; why is `suspend()` a function and not a statement? > Yes, suspend() is a function from the Async namespace. I couldn't find any strong reasons to define it as an operator: ```php suspend(); // vs suspend; ``` For example, the spawn operator makes the c

Re: [PHP-DEV] PHP True Async RFC - Stage 2

On 16/03/2025 09:24, Edmond Dantes wrote: Good day, everyone. I hope you're doing well. https://wiki.php.net/rfc/true_async Here is a new version of the RFC dedicated to asynchrony. Key differences from the previous version: * The RFC is not based on Fiber; it introduces a separate class rep

[PHP-DEV] PHP True Async RFC - Stage 2

Good day, everyone. I hope you're doing well. https://wiki.php.net/rfc/true_async Here is a new version of the RFC dedicated to asynchrony. Key differences from the previous version: * The RFC is not based on Fiber; it introduces a separate class representation for the asynchronous context. * A

Re: [PHP-DEV] PHP True Async RFC

> > Yeah, this is a Watcher, a periodic function that is called to clean up or > check something. Yes, it’s a very specific pattern. And of course, the > Watcher belongs to the service. If the service is destroyed, the Watcher > should also be stopped. It’s a Async\Interval, but it behaves ent

Re: [PHP-DEV] PHP True Async RFC

On Sat, Mar 8, 2025, at 09:06, Eugene Sidelnyk wrote: >> > >> The uncoloring of functions in PHP is probably one of the most annoying >> aspects of fibers, IMHO. It's hard to explain unless you've been using them >> awhile. But, with colored functions, the caller has control over when the >>

[PHP-DEV] PHP 8.2.28 Released!

The PHP development team announces the immediate availability of PHP 8.2.28. This is a security release that addresses CVE-2025-1219, CVE-2025-1736, CVE-2025-1861, CVE-2025-1734 and CVE-2025-1217. All PHP 8.2 users are advised to upgrade to this version. For source downloads of PHP 8.2.28 please

[PHP-DEV] PHP 8.1.32 Released

The PHP development team announces the immediate availability of PHP 8.1.32. This is a security release that addresses CVE-2024-11235, CVE-2025-1219, CVE-2025-1736, CVE-2025-1861, CVE-2025-1734, and CVE-2025-1217. All PHP 8.1 users are encouraged to upgrade to this version. For source downloads

[PHP-DEV] PHP 8.4.5 Released

The PHP development team announces the immediate availability of PHP 8.4.5. This is a security release that addresses CVE-2024-11235, CVE-2025-1219, CVE-2025-1736, CVE-2025-1861, CVE-2025-1734, and CVE-2025-1217. The PHP development team announces the immediate availability of PHP 8.4.5. This is

[PHP-DEV] PHP 8.3.19 Released

The PHP development team announces the immediate availability of PHP 8.3.19. This is a security release that addresses CVE-2024-11235, CVE-2025-1219, CVE-2025-1736, CVE-2025-1861, CVE-2025-1734, and CVE-2025-1217. All PHP 8.3 users are encouraged to upgrade to this version. (The 8.3.18 releas

Re: Fwd: [PHP-DEV] PHP True Async RFC

On Fri, Mar 7, 2025, at 09:48, Edmond Dantes wrote: > > > > > As far as I know, all current SAPIs follow one of two patterns: > > > > It seems that my example, although taken from real life, is more of an > anti-pattern. Let's take a real example that is not an anti-pattern. > > There is a B

Re: [PHP-DEV] PHP True Async RFC

> > Sure: > Yeah, this is a Watcher, a periodic function that is called to clean up or check something. Yes, it’s a very specific pattern. And of course, the Watcher belongs to the service. If the service is destroyed, the Watcher should also be stopped. In the context of this RFC, it's better t

Re: [PHP-DEV] PHP True Async RFC

> Let me summarize the current state for today: > > I am abandoning startScheduler and the idea of preserving backward > compatibility with await_all or anything else in that category. The scheduler > will be initialized implicitly, and this does not concern user-land. > Consequently, the spaw

Re: [PHP-DEV] PHP True Async RFC

> > As noted, I am in broad agreement with the previously linked article on "playpens" (even if I hate that name), that the "go style model" is too analogous to goto statements. > The syntax and logic you describe are very close to Kotlin's implementation. I would say that Kotlin is probably the

Re: [PHP-DEV] PHP True Async RFC

On Sun, Mar 9, 2025, at 11:56 AM, Edmond Dantes wrote: > *Let me summarize the current state for today:* > > 1. I am abandoning `startScheduler` and the idea of preserving > backward compatibility with `await_all` or anything else in that > category. The scheduler will be initialized implicitly

Re: [PHP-DEV] PHP True Async RFC

> > I can give you several examples where such logic is used in Amphp libraries, and it will break if they are invoked within an async block. > Got it, it looks like I misunderstood the post due to my focus. So, essentially, you're talking not so much about wait_all itself, but rather about the p

Re: [PHP-DEV] PHP True Async RFC

> 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*.  > > It sounds like you think: > > 1) The language absolutely needs a "spawn detached" operation, i.e. a way of > st

Re: [PHP-DEV] PHP True Async RFC

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 {} bl

Re: [PHP-DEV] PHP True Async RFC

> > Maybe, we could create a different version of fibers ("managed fibers", maybe?) distinct from the current implementation, with the idea to deprecate them in PHP 10? > Then, at least, the scheduler could always be running. If you are using existing code that > uses fibers, you can't use the new

Re: [PHP-DEV] PHP True Async RFC

>> The wait_all block is EXPLICITLY DESIGNED to meddle with the internals of >>async libraries, >> > > How exactly does it interfere with the implementation of asynchronous > libraries?  > Especially considering that these libraries operate at the User-land level? > It’s a contract. No more. No

Re: [PHP-DEV] PHP True Async RFC

> > Have a different method `Fiber::suspendToScheduler(Resume $resume)` that would return the control to the Scheduler. > That's exactly how it works. The RFC includes the method Async\wait() (Fiber::await() is nice), which hands control over to the Scheduler. At the PHP core level, there is an eq

Re: [PHP-DEV] PHP True Async RFC

On Sun, Mar 9, 2025, at 09:05, Edmond Dantes wrote: > Good day, Alex. > > > > > Can you please share a bit more details on how the Scheduler is > > implemented, to make sure that I understand why this contradiction exists? > > Also with some examples, if possible. > > > > ```php > $fiber1 = ne

Re: [PHP-DEV] PHP True Async RFC

On Sun, Mar 9, 2025, 09:05 Edmond Dantes wrote: > When a *Fiber* from the *Scheduler* decides to create another *Fiber* and > then tries to call blocking functions inside it, control can no longer > return to the *Scheduler* from those functions. > > Of course, it would be possible to track the s

Re: [PHP-DEV] PHP True Async RFC

> > The wait_all block is EXPLICITLY DESIGNED to meddle with the internals of async libraries, > How exactly does it interfere with the implementation of asynchronous libraries? Especially considering that these libraries operate at the User-land level? It’s a contract. No more. No less. > > Lib

Re: [PHP-DEV] PHP True Async RFC

Good day, Alex. > > Can you please share a bit more details on how the Scheduler is implemented, to make sure that I understand why this contradiction exists? Also with some examples, if possible. > ```php $fiber1 = new Fiber(function () { echo "Fiber 1 starts\n"; $fiber2 = new Fiber(fu

Re: [PHP-DEV] PHP True Async RFC

On 8 March 2025 13:38:30 GMT, Daniil Gentili wrote: > >> The async block as I'm picturing it has nothing to do with function >> colouring, it's about the outermost function in an async stack being able to >> say "make sure the scheduler is started" and "block here until all child >> fibers a

Re: [PHP-DEV] PHP True Async RFC

> Offering this tool to userland is a major footgun that will either backfire > spectacularly (breaking existing and new async libraries by endlessly > awaiting upon background fibers when exiting an async {} block haphazardly > used by a newbie, or even worse force library developers to reduce

Re: [PHP-DEV] PHP True Async RFC

Hi Edmond, On Sat, Mar 8, 2025, 19:18 Edmond Dantes wrote: > This situation is solely due to the fact that the Scheduler contradicts of > Fiber. > >- The Scheduler expects to switch contexts as it sees fit. >- Fiber expects context switching to occur only between the >Fiber-parent an

Re: [PHP-DEV] PHP True Async RFC

Hi, To see to be posting a reply to nearly every other email on this thread. I'd recommend you have another read through our mailing list rules: cheers Derick On 8 March 2025 22:28:58 GMT, Daniil Gentili wrote: >>> To m

Re: [PHP-DEV] PHP True Async RFC

>> To make an analogy, it's like saying PHP should have an io {} block, that >> makes sure all file resources opened within (even internally, 10 stack >> levels deep into 3 libraries, whose instances are all used after the io {} >> block) are closed when exiting. > > Traditional PHP offers exact

Re: [PHP-DEV] PHP True Async RFC

>>  Crippling async PHP with async blocks just because some libraries aren't >>ready for concurrency now, means crippling the future of async php. >> > How can calling a single function have such a destructive impact on the > future of PHP?  Very simple: to make an analogy, it's like saying PH

Re: [PHP-DEV] PHP True Async RFC

On 8 March 2025 21:42:21 GMT, Daniil Gentili wrote: > >To make an analogy, it's like saying PHP should have an io {} block, that >makes sure all file resources opened within (even internally, 10 stack levels >deep into 3 libraries, whose instances are all used after the io {} block) are >clo

Re: [PHP-DEV] PHP True Async RFC

>>> The async block as I'm picturing it has nothing to do with function >>> colouring, it's about the outermost function in an async stack being able >>> to say "make sure the scheduler is started" and "block here until all child >>> fibers are either concluded, detached, or cancelled". >> >> T

  1   2   3   4   5   6   7   8   9   10   >