Re: Re: PHP True Async RFC Stage 5
Hello, Luís.
> Maybe keep the base Awaitable internal and expose two userland interfaces that match the two
> cases described in the RFC:
Yes, that option is possible, but I want to share my current line of thinking:
1. I’d really like to keep the name Future for the Future class,
which is planned for upcoming RFCs.
2. I have some doubts that the name Streamable precisely conveys the
intended meaning (example Signals). However, if our colleagues who are
native English speakers say it’s a good choice, I have no objections.
> Questions (self-cancellation) 1. What happens here?
Here’s what happens:
1. The coroutine continues running successfully until completion.
2. The code that calls await() receives a
CancellationError("Self-cancelled") exception.
Originally, the idea was to throw an exception directly from
cancel(), but that would require adding an extra try-catch block.
So I decided to keep it silent instead.
> Can a cancelled coroutine suspend?
Nothing will happen.
When cancel() is called, PHP detects that it’s the current coroutine
and only sets the exception as its result.
Later, when suspend() is invoked, it creates a new waker object that
has no exception, so after resuming, no exception occurs.
Do you think this case should be additionally described in the RFC?
So, that would give developers a better understanding.
Sometimes a coroutine doesn’t cancel itself but its own Scope,
and the developer should understand that if they cancel a Scope that
includes the current coroutine, they need to finish its work properly
from within.
> Which error does await() throw in this case — CancellationError or RuntimeException?
RuntimeException, because this exception will override the previous one.
There is more logic here than described in the RFC, because there is
an “override” rule.
Exceptions of the CancellationError class do not override each
other. The first cancellation reason is always visible.
However, if an unhandled exception of another class occurs, it will
replace the CancellationError.
In other words, the logic follows these rules:
1. The first cancellation reason takes precedence over subsequent ones.
2. Unexpected errors take precedence over CancellationError.
So, when a developer tries to cancel a coroutine more than once, it
has no effect.
> It’d be great to clarify that in the docs, since it affects where people put cleanup,
> logging, etc.
This case should be described in more detail in the RFC.
Thank you for noticing it!
> Again, thanks for the work, especially on such an important feature for PHP’s future.
Thank you for your excellent feedback, it’s very inspiring.
---
Best Regards, Ed
Thread (3 messages)