[VOTE] True Async RFC 1.6

1 day ago by Derick Rethans — view source — reply

unread

Hello all

According to all previous discussions, version 1.6 of this RFC has
been prepared and is now being submitted for a vote:

Voting Page: https://wiki.php.net/rfc/true_async/voting
RFC https://wiki.php.net/rfc/true_async

The vote officially starts tomorrow, as previously announced.

Why is the voting widget not on the RFC page where it belongs?

cheers
Derick

1 day ago by Matteo Beccati — view source — reply

unread

Hi,

Il 19/11/2025 14:24, Derick Rethans ha scritto:

Hello all

According to all previous discussions, version 1.6 of this RFC has
been prepared and is now being submitted for a vote:

Voting Page: https://wiki.php.net/rfc/true_async/voting
RFC https://wiki.php.net/rfc/true_async

The vote officially starts tomorrow, as previously announced.

Why is the voting widget not on the RFC page where it belongs?

Also it's weird to get a [VOTE] email when voting is not open yet.

Cheers

Matteo Beccati

1 day ago by Edmond Dantes — view source — reply

unread

Hello, Matteo

Why is the voting widget not on the RFC page where it belongs?

Unfortunately, I wasn’t able to understand exactly how the voting
process works, so I created a separate page. But if the vote is
supposed to be included in the RFC itself, please ignore it.

Also it's weird to get a [VOTE] email when voting is not open yet.
I’m sorry, this really is strange.

9 hours ago by Rowan Tommins [IMSoP] — view source — reply

unread

Unfortunately, I wasn’t able to understand exactly how the voting
process works, so I created a separate page. But if the vote is
supposed to be included in the RFC itself, please ignore it.

I guess you didn't see my reply when you asked this before. Here again
is the link to the instructions: https://wiki.php.net/rfc/howto

Can you tell us where you got the idea that there needed to be a
separate page? Maybe there is some text that we can make clearer.

Meanwhile, please cancel this vote. There is no rush.

If we get it right, this could be the most significant feature added to
PHP for 10 years or more. If we get it wrong, we might regret it for 20
years.

On Monday, you replied to a message from Bart Vanhoutte, saying:

Hello Bart.
I am ready to agree with every word.

Participation from a working group, framework representatives, and the
ability to adapt libraries in advance would remove the concerns that
are currently causing fear. This is probably the only effective
process for developing and introducing such a feature.

Then two days later, you decided that no more discussion was necessary,
and opened a vote.

This feels like a complete contradiction.

Let's find a way to get that working group set up, and get people from
other projects involved.

I am extremely grateful and frankly amazed for all the work you've put
into this. Please don't throw that away by ending up with a "No" vote
over small details.

--
Rowan Tommins
[IMSoP]

8 hours ago by Daniil Gentili — view source — reply

unread

Hi,

Hello Bart.
I am ready to agree with every word.

Participation from a working group, framework representatives, and the
ability to adapt libraries in advance would remove the concerns that
are currently causing fear. This is probably the only effective
process for developing and introducing such a feature.

Then two days later, you decided that no more discussion was
necessary, and opened a vote.

This feels like a complete contradiction.

Let's find a way to get that working group set up, and get people from
other projects involved.

My key takeaway from Bart's message is:

Moreover, even though there are quite a few people in the community
who have the knowledge required because they either develop or work with
aforementioned libraries or extensions, (almost) none of them seem to be
involved in discussing this RFC.
For an RFC that can drastically change the way we develop
applications I would expect more experts on this matter to be involved.
Ideally, PHP core developers, library developers & maintainers, IDE
developers, ..., would develop software using this branch to at least
get some feel for the paradigm and this RFC in general.

I absolutely agree with this take, however, so far, the discussion
around this RFC has been, in my opinion, mostly bikeshedding, with
theoretical correctness proposals that are an absolute nightmare in
practice (like structured concurrency), proposed by people that
admittedly have never written extensive amounts of async code in
languages using multiple paradigms, and thus haven't:

Experienced the pain of writing async with colored functions
Experienced the footguns of structured concurrency
And on the other hand, haven't experienced the pleasure and simplicity
of safely writing async code in languages like Go, or in PHP using AMPHP
(which use uncolored and unstructured concurrency, the kind proposed and
championed by edmond)

While a working group can steer the conversation away from
theoretically correct but practically unusable approaches, that can
happen only if

The correct people (i.e. async library maintainers, or people that
write async logic every day in multiple languages like myself) are present
They are given more weight than the average PHP developer who hasn't
used async much if at all, and can only make theoretical proposals not
based on practice and experience

I'm afraid that given the current state of the PHP community, which is
largely new to async, the quality of the conversation in a working group
would not be much higher than the one I'm seeing in this RFC, and would
just protract even longer the agony of design by committee, where in
reality what's needed is a single, clear and correct vision (which
Edmond has), without influences from unexperienced people making
proposals based purely on abstract/theoretical PoVs.

Regards,

Daniil Gentili.

7 hours ago by Deleu — view source — reply

unread

On Thu, 20 Nov 2025 at 07:21 Daniil Gentili daniil.gentili@gmail.com
wrote:

Hi,

Hello Bart.
I am ready to agree with every word.

Participation from a working group, framework representatives, and the
ability to adapt libraries in advance would remove the concerns that
are currently causing fear. This is probably the only effective
process for developing and introducing such a feature.

Then two days later, you decided that no more discussion was
necessary, and opened a vote.

This feels like a complete contradiction.

Let's find a way to get that working group set up, and get people from
other projects involved.

My key takeaway from Bart's message is:

Moreover, even though there are quite a few people in the community
who have the knowledge required because they either develop or work with
aforementioned libraries or extensions, (almost) none of them seem to be
involved in discussing this RFC.
For an RFC that can drastically change the way we develop
applications I would expect more experts on this matter to be involved.
Ideally, PHP core developers, library developers & maintainers, IDE
developers, ..., would develop software using this branch to at least
get some feel for the paradigm and this RFC in general.

I absolutely agree with this take, however, so far, the discussion
around this RFC has been, in my opinion, mostly bikeshedding, with
theoretical correctness proposals that are an absolute nightmare in
practice (like structured concurrency), proposed by people that
admittedly have never written extensive amounts of async code in
languages using multiple paradigms, and thus haven't:

Experienced the pain of writing async with colored functions

Experienced the footguns of structured concurrency

And on the other hand, haven't experienced the pleasure and simplicity
of safely writing async code in languages like Go, or in PHP using AMPHP
(which use uncolored and unstructured concurrency, the kind proposed and
championed by edmond)

While a working group can steer the conversation away from
theoretically correct but practically unusable approaches, that can
happen only if

The correct people (i.e. async library maintainers, or people that
write async logic every day in multiple languages like myself) are present

They are given more weight than the average PHP developer who hasn't
used async much if at all, and can only make theoretical proposals not
based on practice and experience

I'm afraid that given the current state of the PHP community, which is
largely new to async, the quality of the conversation in a working group
would not be much higher than the one I'm seeing in this RFC, and would
just protract even longer the agony of design by committee, where in
reality what's needed is a single, clear and correct vision (which
Edmond has), without influences from unexperienced people making
proposals based purely on abstract/theoretical PoVs.

Regards,

Daniil Gentili.

While I certainly can sympathize with the painful, dreadful, unpleasant,
unbearable agony of debating a subject with “non-experts”, it’s important
to have some perspective in the opposite direction.

As it has been mentioned before, Async PHP in general is practically a
rounding error in terms of user base and there are reasons for that. It’s
important to remember that the benefits of async doesn’t always justify the
burden that it brings. For PHP as a language to adopt an async solution
natively it’s very important that sync code continues to function while
also allowing developers to opt into async without having to feel like they
changed languages and must re-learn how to manage their projects. If this
is not possible then perhaps the current state is as good as we can ever
get: let expert matter install their extension (opt-in) on a per-project
basis.

It's going to be up to the subject experts to come up with a path that
allows PHP to stay coherent while offering both approaches. To put this in
another way: RFC Voters are above average PHP developers. If they're unable
to digest the changes being proposed, even if said changes are being
proposed by the single most subject-expert human on the planet, then how do
we expect average PHP developers to make good use of it?

3 hours ago by Jakub Zelenka — view source — reply

unread

On Thu, 20 Nov 2025 at 07:21 Daniil Gentili daniil.gentili@gmail.com
wrote:

Hi,

Hello Bart.
I am ready to agree with every word.

Participation from a working group, framework representatives, and the
ability to adapt libraries in advance would remove the concerns that
are currently causing fear. This is probably the only effective
process for developing and introducing such a feature.

Then two days later, you decided that no more discussion was
necessary, and opened a vote.

This feels like a complete contradiction.

Let's find a way to get that working group set up, and get people from
other projects involved.

My key takeaway from Bart's message is:

Moreover, even though there are quite a few people in the community
who have the knowledge required because they either develop or work with
aforementioned libraries or extensions, (almost) none of them seem to be
involved in discussing this RFC.
For an RFC that can drastically change the way we develop
applications I would expect more experts on this matter to be involved.
Ideally, PHP core developers, library developers & maintainers, IDE
developers, ..., would develop software using this branch to at least
get some feel for the paradigm and this RFC in general.

I absolutely agree with this take, however, so far, the discussion
around this RFC has been, in my opinion, mostly bikeshedding, with
theoretical correctness proposals that are an absolute nightmare in
practice (like structured concurrency), proposed by people that
admittedly have never written extensive amounts of async code in
languages using multiple paradigms, and thus haven't:

Experienced the pain of writing async with colored functions

Experienced the footguns of structured concurrency

And on the other hand, haven't experienced the pleasure and simplicity
of safely writing async code in languages like Go, or in PHP using AMPHP
(which use uncolored and unstructured concurrency, the kind proposed and
championed by edmond)

While a working group can steer the conversation away from
theoretically correct but practically unusable approaches, that can
happen only if

The correct people (i.e. async library maintainers, or people that
write async logic every day in multiple languages like myself) are present

They are given more weight than the average PHP developer who hasn't
used async much if at all, and can only make theoretical proposals not
based on practice and experience

I'm afraid that given the current state of the PHP community, which is
largely new to async, the quality of the conversation in a working group
would not be much higher than the one I'm seeing in this RFC, and would
just protract even longer the agony of design by committee, where in
reality what's needed is a single, clear and correct vision (which
Edmond has), without influences from unexperienced people making
proposals based purely on abstract/theoretical PoVs.

Regards,

Daniil Gentili.

While I certainly can sympathize with the painful, dreadful, unpleasant,
unbearable agony of debating a subject with “non-experts”, it’s important
to have some perspective in the opposite direction.

As it has been mentioned before, Async PHP in general is practically a
rounding error in terms of user base and there are reasons for that. It’s
important to remember that the benefits of async doesn’t always justify the
burden that it brings. For PHP as a language to adopt an async solution
natively it’s very important that sync code continues to function while
also allowing developers to opt into async without having to feel like they
changed languages and must re-learn how to manage their projects. If this
is not possible then perhaps the current state is as good as we can ever
get: let expert matter install their extension (opt-in) on a per-project
basis.

It's going to be up to the subject experts to come up with a path that
allows PHP to stay coherent while offering both approaches. To put this in
another way: RFC Voters are above average PHP developers. If they're unable
to digest the changes being proposed, even if said changes are being
proposed by the single most subject-expert human on the planet, then how do
we expect average PHP developers to make good use of it?

Yeah I think this is one of the reasons why the RFC failed. It couldn't
properly explain the topic even though it was reduced to minimum. One of
the factor is certainly that Edmond is new to the RFC process but more
importantly it's quite contentious topic that can bring even more bike
shedding. I think there were some important points raised in the
discussions about safety of the existing sync code which I think might be
the real killer here. So even if we omit the mix up with the
pre-announcement and sudden voting (that were sure path to rejection), I
think the bigger problem is the whole size of the feature and the fact that
it will be extremely hard to find any solution that will please majority of
voters. I'm honestly not sure if this is possible to get to any form that
can pass. I would like to be wrong but we can see the reality here.

I think the way forward for PHP is to do what we have been doing and it is
to provide the building blocks for user space to enable async there because
that's something that can be reasonably introduced using the RFC through
smaller chunks. It means improving the non blocking setup, exposing IO
hooks, better polling and other primitives. That was actually the plan in
past and that's why it is also contained in my STF stream work where the
scope was created way before the TrueAsync.

Kind regards,

Jakub

37 minutes ago by luisvscbarros@gmail.com — view source — reply

unread

Hi

What I understand from this is that the voters are not willing to make any
concessions to include a feature that is important to at least 10% of the
developers in the PHP ecosystem (someone mentioned 10% in an earlier email;
I would guess the number is even higher, considering China). It’s important
for us, who are part of that 10% that apparently isn’t important enough to
be heard, to know what the voters’ stance actually is regarding the
introduction of tooling for Async in PHP. That way we can understand what
the next step needs to be: whether we take on the difficult job of
migrating our software from PHP to another platform, or the impossible job
of trying to convince people who are not willing to be convinced.

Regards,

Luís Vinícius

Em qui., 20 de nov. de 2025, 12:44, Jakub Zelenka bukka@php.net escreveu:

On Thu, 20 Nov 2025 at 07:21 Daniil Gentili daniil.gentili@gmail.com
wrote:

Hi,

Hello Bart.
I am ready to agree with every word.

Participation from a working group, framework representatives, and the
ability to adapt libraries in advance would remove the concerns that
are currently causing fear. This is probably the only effective
process for developing and introducing such a feature.

Then two days later, you decided that no more discussion was
necessary, and opened a vote.

This feels like a complete contradiction.

Let's find a way to get that working group set up, and get people from
other projects involved.

My key takeaway from Bart's message is:

Moreover, even though there are quite a few people in the community
who have the knowledge required because they either develop or work with
aforementioned libraries or extensions, (almost) none of them seem to be
involved in discussing this RFC.
For an RFC that can drastically change the way we develop
applications I would expect more experts on this matter to be involved.
Ideally, PHP core developers, library developers & maintainers, IDE
developers, ..., would develop software using this branch to at least
get some feel for the paradigm and this RFC in general.

I absolutely agree with this take, however, so far, the discussion
around this RFC has been, in my opinion, mostly bikeshedding, with
theoretical correctness proposals that are an absolute nightmare in
practice (like structured concurrency), proposed by people that
admittedly have never written extensive amounts of async code in
languages using multiple paradigms, and thus haven't:

Experienced the pain of writing async with colored functions

Experienced the footguns of structured concurrency

And on the other hand, haven't experienced the pleasure and simplicity
of safely writing async code in languages like Go, or in PHP using AMPHP
(which use uncolored and unstructured concurrency, the kind proposed and
championed by edmond)

While a working group can steer the conversation away from
theoretically correct but practically unusable approaches, that can
happen only if

The correct people (i.e. async library maintainers, or people that
write async logic every day in multiple languages like myself) are
present

They are given more weight than the average PHP developer who hasn't
used async much if at all, and can only make theoretical proposals not
based on practice and experience

I'm afraid that given the current state of the PHP community, which is
largely new to async, the quality of the conversation in a working group
would not be much higher than the one I'm seeing in this RFC, and would
just protract even longer the agony of design by committee, where in
reality what's needed is a single, clear and correct vision (which
Edmond has), without influences from unexperienced people making
proposals based purely on abstract/theoretical PoVs.

Regards,

Daniil Gentili.

While I certainly can sympathize with the painful, dreadful, unpleasant,
unbearable agony of debating a subject with “non-experts”, it’s important
to have some perspective in the opposite direction.

As it has been mentioned before, Async PHP in general is practically a
rounding error in terms of user base and there are reasons for that. It’s
important to remember that the benefits of async doesn’t always justify the
burden that it brings. For PHP as a language to adopt an async solution
natively it’s very important that sync code continues to function while
also allowing developers to opt into async without having to feel like they
changed languages and must re-learn how to manage their projects. If this
is not possible then perhaps the current state is as good as we can ever
get: let expert matter install their extension (opt-in) on a per-project
basis.

It's going to be up to the subject experts to come up with a path that
allows PHP to stay coherent while offering both approaches. To put this in
another way: RFC Voters are above average PHP developers. If they're unable
to digest the changes being proposed, even if said changes are being
proposed by the single most subject-expert human on the planet, then how do
we expect average PHP developers to make good use of it?

Yeah I think this is one of the reasons why the RFC failed. It couldn't
properly explain the topic even though it was reduced to minimum. One of
the factor is certainly that Edmond is new to the RFC process but more
importantly it's quite contentious topic that can bring even more bike
shedding. I think there were some important points raised in the
discussions about safety of the existing sync code which I think might be
the real killer here. So even if we omit the mix up with the
pre-announcement and sudden voting (that were sure path to rejection), I
think the bigger problem is the whole size of the feature and the fact that
it will be extremely hard to find any solution that will please majority of
voters. I'm honestly not sure if this is possible to get to any form that
can pass. I would like to be wrong but we can see the reality here.

I think the way forward for PHP is to do what we have been doing and it is
to provide the building blocks for user space to enable async there because
that's something that can be reasonably introduced using the RFC through
smaller chunks. It means improving the non blocking setup, exposing IO
hooks, better polling and other primitives. That was actually the plan in
past and that's why it is also contained in my STF stream work where the
scope was created way before the TrueAsync.

Kind regards,

Jakub

6 hours ago by Rob Landers — view source — reply

unread

Hi,

Hello Bart.
I am ready to agree with every word.

Participation from a working group, framework representatives, and the
ability to adapt libraries in advance would remove the concerns that
are currently causing fear. This is probably the only effective
process for developing and introducing such a feature.

Then two days later, you decided that no more discussion was
necessary, and opened a vote.

This feels like a complete contradiction.

Let's find a way to get that working group set up, and get people from
other projects involved.

My key takeaway from Bart's message is:

Moreover, even though there are quite a few people in the community
who have the knowledge required because they either develop or work with
aforementioned libraries or extensions, (almost) none of them seem to be
involved in discussing this RFC.
For an RFC that can drastically change the way we develop
applications I would expect more experts on this matter to be involved.
Ideally, PHP core developers, library developers & maintainers, IDE
developers, ..., would develop software using this branch to at least
get some feel for the paradigm and this RFC in general.

I absolutely agree with this take, however, so far, the discussion
around this RFC has been, in my opinion, mostly bikeshedding, with
theoretical correctness proposals that are an absolute nightmare in
practice (like structured concurrency), proposed by people that
admittedly have never written extensive amounts of async code in
languages using multiple paradigms, and thus haven't:

Experienced the pain of writing async with colored functions

Experienced the footguns of structured concurrency

And on the other hand, haven't experienced the pleasure and simplicity
of safely writing async code in languages like Go, or in PHP using AMPHP
(which use uncolored and unstructured concurrency, the kind proposed and
championed by edmond)

While a working group can steer the conversation away from
theoretically correct but practically unusable approaches, that can
happen only if

The correct people (i.e. async library maintainers, or people that
write async logic every day in multiple languages like myself) are present

They are given more weight than the average PHP developer who hasn't
used async much if at all, and can only make theoretical proposals not
based on practice and experience

I'm afraid that given the current state of the PHP community, which is
largely new to async, the quality of the conversation in a working group
would not be much higher than the one I'm seeing in this RFC, and would
just protract even longer the agony of design by committee, where in
reality what's needed is a single, clear and correct vision (which
Edmond has), without influences from unexperienced people making
proposals based purely on abstract/theoretical PoVs.

Regards,

Daniil Gentili.

I kind of take offence to this statement. First of all, I work almost exclusively in Go these days, and on FrankenPHP. I only brought up colored functions twice, because literally every language that has attempted the proposed solution here have all reversed course and implemented coloured functions. I've hand-written schedulers in C# (which is also cooperatively scheduled).

Second, Go has a tremendous amount of primitives for dealing with concurrency: wait groups, locks, atomics, etc. This proposal has none of that, hence my concern with suspension points.

Further, I have worked with AMPHP extensively since it's generator-based days on multiple projects, and with Fibers quite extensively as well. So saying "proposed by people that admittedly have never written extensive amounts of async code in languages using multiple paradigms" is factually untrue.

— Rob

5 hours ago by Edmond Dantes — view source — reply

unread

Hello

I'm afraid that given the current state of the PHP community, which is
largely new to async, the quality of the conversation in a working group
would not be much higher than the one I'm seeing in this RFC

I’m afraid I have to agree with every word said here, even though we
don’t know each other and have never spoken before.
And this post is the most honest explanation of the current situation.

Ed

5 hours ago by Edmond Dantes — view source — reply

unread

Hello

Here again is the link to the instructions: https://wiki.php.net/rfc/howto
I think it was just my internal feeling that voting on a page with a
lot of text is inconvenient. So I tried to find some solution in the
documentation. That’s why I thought that having the voting on a
separate page would probably be the right thing.
Anyway, don’t pay attention to it

On Monday, you replied to a message from Bart Vanhoutte, saying:
Yes, I was unexpectedly surprised that someone suggested the same
thing I had proposed a few months earlier.
That proposal also included a separate workflow for TrueAsync, which
would keep it in a special experimental status for at least six months
or a year.

Let's find a way to get that working group set up, and get people from other projects involved.
There were never any objections from my side.
But it seems to me that people have made their choice. And that’s okay.

Ed

1 day ago by Edmond Dantes — view source — reply

unread

Hello, Derick

Why is the voting widget not on the RFC page where it belongs?
It was fixed.
Please use: https://wiki.php.net/rfc/true_async#voting_choices

1 day ago by tim@bastelstu.be — view source — reply

unread

Hi

Am 2025-11-19 13:35, schrieb Edmond Dantes:

According to all previous discussions, version 1.6 of this RFC has
been prepared and is now being submitted for a vote:

Voting Page: https://wiki.php.net/rfc/true_async/voting
RFC https://wiki.php.net/rfc/true_async

The vote officially starts tomorrow, as previously announced.

I'm seeing that you added the full API stub of the proposed API on
November 13 (which I'm only seeing now, did I miss an email where you
mentioned that you made the change?). I'm afraid to note that the
proposed API is in violation of our policy regarding Throwables:
https://github.com/php/policies/blob/main/coding-standards-and-naming.rst#throwables.
Particularly, there the “base exception” for the Async namespace is
missing. I'm only noticing it now with the stub, since the exact class
hierarchy was not mentioned in the RFC before.

Given the policy violation I believe that the RFC is unfit to go to vote
in the current state.

Best regards
Tim Düsterhus

1 day ago by Edmond Dantes — view source — reply

unread

Hello.

I'm afraid to note that the proposed API is in violation of our policy regarding Throwables
Thank you. It was fixed.

1 day ago by tim@bastelstu.be — view source — reply

unread

Hi

Am 2025-11-19 16:19, schrieb Edmond Dantes:

I'm afraid to note that the proposed API is in violation of our policy
regarding Throwables
Thank you. It was fixed.

That is not quite right. The base exception should be
\Async\AsyncException. I am also noticing that you changed the
DeadlockError to DeadlockException which is a significant change
from the previous proposal. The Error hierarchy is meant for problems
that are not expected to be caught, because they cannot usefully be
handled. The Exception hierarchy is something that should be caught.

Given that the RFC says (highlighting mine):

This condition is called a Deadlock, and it represents a serious
logical error.

I believe it should be a DeadlockError like it originally proposed.
That one should then extend \Async\AsyncError and similarly
\Async\AsyncError should extend `\Error.

Similarly for CancellationError. It should extend \Async\AsyncError.
I'm seeing the comment “Does not extend Exception to avoid accidental
suppression” which makes sense to me, but the Error hierarchy
specifically isn't an Exception. And folks catching \Throwable will
catch CancellationError as well, so I don't see a reason why it should
be treated differently in this regard.

Looking at the stub more carefully, I'm also seeing that
\Async\gracefulShutdown() should be \Async\graceful_shutdown()
instead (and similarly for currentCoroutine() -> current_coroutine()
and getCoroutines() -> get_coroutines()). This is something that I
could have caught earlier and I'm sorry that I did not. However since
changes to the RFC will still be required (which means that the vote
will need to be cancelled), it probably makes sense to fix that as well.

Best regards
Tim Düsterhus

1 day ago by Edmond Dantes — view source — reply

unread

Hello.

I believe it should be a DeadlockError like it originally proposed.
Thank you, this is worth discussing.

1 day ago by kontakt@beberlei.de — view source — reply

unread

Am 19.11.2025, 13:35:13 schrieb Edmond Dantes edmond.ht@gmail.com:

Hello all

According to all previous discussions, version 1.6 of this RFC has
been prepared and is now being submitted for a vote:

Voting Page: https://wiki.php.net/rfc/true_async/voting
RFC https://wiki.php.net/rfc/true_async

voted No soley because of the API design problems that Tim mentioned and
needs to be addressed before voting.

Its not a vote on the merits of the RFC in general.

The vote officially starts tomorrow, as previously announced.

For version 1.6 the following important change was made:
All input/output functions are now bound by the shared requirement of
being non-blocking with respect to the process. However, the specific
behavior of each function may (optionally) be defined in separate
RFCs.

Thus, I/O functions themselves are not part of this RFC, but the main
RFC defines the general way in which they must operate. Thus (as I see
it), the RFC achieves a balance between cohesion and separation of
concerns.

Since the discussion period has ended, I will not be engaging in
further debate (except regarding the voting process itself). If you
have any questions for me of any kind, you may ask them either in a
separate thread or privately. (This also means that I will not be
answering RFC-related questions in this thread). I will be glad to
hear your opinions and feedback. I wish all participants the best of
luck.

Best Regards, Ed

1 day ago by Bob Weinand — view source — reply

unread

Hello Edmond,

Hello all

According to all previous discussions, version 1.6 of this RFC has
been prepared and is now being submitted for a vote:

Voting Page: https://wiki.php.net/rfc/true_async/voting
RFC https://wiki.php.net/rfc/true_async

The vote officially starts tomorrow, as previously announced.

This comes a bit of sudden. For sure, you respected the minimum
discussion period, though there was still active discussion just
yesterday and the few days before.

I was also planning to give the now shortened variant of the RFC a
thorough read and read the discussions around it.

Others seem to also indicate that there were still a couple open points
for discussion - thus I would advise you to cancel the vote and discuss
these points first, then go ahead with a vote again a week later.

My own thoughts on the RFC (from just reading the RFC in depth, without
considering prior conversations now):

I agree with the choices of separating Fiber and Coroutine, but I
disagree that there's a fundamental problem with allowing Fibers in
Coroutines. A Fiber is essentially just a stackful generator, from a
very-high-level perspective. You allow generators to be used with
Coroutines. There should be no fundamental reason this isn't possible.
It just might require some refactoring of the code to manage it properly
(i.e. just like you cannot continue a generator which is currently
active, but suspended in a fiber, you should not be able to resume a
fiber which is currently active, but suspended in a coroutine).

Cancellation is not an Error - Errors are generally for programmer
errors, not for exceptional behaviour. There might be an argument for
making Cancellation a top-level item below Throwable, because it's
really special. But definitely not Error. (And if you do, the RFC should
note a small policy amendment too.)

I'm not particularly fond of the FutureLike name. Is there a reason why
it isn't simply called "Future"?
I know that in an earlier iteration there was a Future class. But Future
is only the promise of a future value. It's the callee API.
Callers can return specific implementations of Future, like "new
Async\Completed(true)", "new Async\Completable" (which has a $future
object as part of its API, which then can be awaited on), "new
Async\Failed($someException)".

A Coroutine should not only offer the current suspend location as API,
but the full stacktrace too. (Like ReflectionFiber does.)

Async\suspend() should maybe be called Async\yield() - as in yielding
control back to the scheduler. Suspension is the observable side-effect
of yielding or awaiting. But you don't actually suspend a coroutine, the
action of suspending is done by the scheduler. [This also would match
terminology used by the linux kernel for example, which calls it
sched_yield(). I think it's misnamed on Fiber.] I don't feel strongly
about that though.

I find it confusing that an "await" operation does not accept Awaitable
as its primary argument, but FutureLike per its signature. Why is that?
The doc for Awaitable says that there can be await calls on those. But
Async\await can't await it? What exactly is an Awaitable then? Would it
essentially be the equivalent of an iterable Future (as in: can be
awaited multiple times)?

Minor nit: Coroutine::onFinally() could be just called Coroutine->finally().

Thank you for working on this,
Bob

44 minutes ago by michal.brzuchalski@gmail.com — view source — reply

unread

śr., 19 lis 2025 o 13:36 Edmond Dantes edmond.ht@gmail.com napisał(a):

Hello all

According to all previous discussions, version 1.6 of this RFC has
been prepared and is now being submitted for a vote:

Voting Page: https://wiki.php.net/rfc/true_async/voting
RFC https://wiki.php.net/rfc/true_async

The vote officially starts tomorrow, as previously announced.

For version 1.6 the following important change was made:
All input/output functions are now bound by the shared requirement of
being non-blocking with respect to the process. However, the specific
behavior of each function may (optionally) be defined in separate
RFCs.

Thus, I/O functions themselves are not part of this RFC, but the main
RFC defines the general way in which they must operate. Thus (as I see
it), the RFC achieves a balance between cohesion and separation of
concerns.

Since the discussion period has ended, I will not be engaging in
further debate (except regarding the voting process itself). If you
have any questions for me of any kind, you may ask them either in a
separate thread or privately. (This also means that I will not be
answering RFC-related questions in this thread). I will be glad to
hear your opinions and feedback. I wish all participants the best of
luck.

Best Regards, Ed

Just a quick clarification regarding my vote.

I cast a “yes” because I wanted to express general support for the idea of
native async in PHP, not because I believed the RFC in its current form was
ready to pass. The ongoing discussion clearly shows there are still open
questions to resolve, and I fully respect that.

My intention was simply to show encouragement for the direction and
acknowledge the work that went into this effort, even if this particular
iteration is unlikely to succeed. I’m absolutely fine with the vote
continuing or being paused if needed — whatever best serves the process.

Regardless of the outcome, I hope the exploration of async in PHP
continues. It’s an important topic, and I appreciate the dedication behind
the proposal.

Cheers,

Michał Marcin Brzuchalski

41 minutes ago by Edmond Dantes — view source — reply

unread

Hello, Michal

Regardless of the outcome, I hope the exploration of async in PHP continues. It’s an important topic, and I appreciate the dedication behind the proposal.
Honest, open, and clear position. Thank you very much!

Ed