> Most RFCs have an example in the introduction of what the proposed syntax > looks like in a small but meaningful example. Please include such, as it > helps "set the stage" and provide context for the rest of the RFC.
usage examples are provided immediately after the API Overview, as agreed. > As I've said before, I'd rather have keywords than functions for the main API. As discussed earlier, introducing new keywords is better addressed in a separate RFC. > getAwaitingInfo(): array - Hell no, no struct arrays. Make it a class. The getAwaitingInfo function is intended to retrieve debugging information that can be used for telemetry or debugging purposes. Different reasons for suspending a coroutine may have different metadata, which is difficult to standardize. Therefore, an associative array with keys is used as the ideal data structure for storing information without a contract, and one that is easy to serialize. > Function name strings should basically never be used again. (Another > argument in favor of keywords.) The question goes beyond the scope of this RFC. However, what would be useful to discuss is the possibility of narrowing the interface down to Closure. For some reason, a year has already passed, and that discussion still has not happened. > "The non-blocking version of the file_get_contents function is not part of > this RFC." - Wait, I'm confused. This is a consequence of the lack of agreement on what should be included in an RFC and what should not. I will remove this block. > The examples seem very inconsistent. Some are using foo(...), The term “inconsistency” cannot be applied in this case, since all examples are consistent with subsets that belong to the same set. In PHP, all these expressions are callable. > - In Fibers, in the basic example, "start() blocks until the fiber completes" > - I assume that means it blocks the calling coroutine? Or does it block the > whole system until it completes? Non-blocking behavior is the default. Therefore, of course, it is the coroutine that is blocked. > - I have no idea what it means for coroutines to be "symmetric". This is > stated as a thing, but I have no clue what that means. That makes much of > the Fibers section incomprehensible. There is a terminology error here. It should be “asymmetric.”: >> Asymmetric coroutine mechanisms (more commonly denoted as semi-symmetric or >> semi coroutines) provide two control-transfer operations: one for invoking a >> coroutine and one for suspending it, the latter returning control to the >> coroutine invoker. >> While symmetric coroutines operate at the same >> hierarchical level, an asymmetric coroutine can be regarded as subordinate >> to its caller, the relationship between them being somewhat similar to that >> between a called and a calling routine. In other words, according to the official PHP documentation, the following conditions must be met: >> Suspends execution of the current fiber. The value provided to this method >> will be returned from the call to Fiber::start(), Fiber::resume(), or >> Fiber::throw() that switched execution into the current fiber. > - I will have to defer to the existing async gurus This is not complex enough to require asking a guru. Fibers transfer control according to the following scheme: ``` Fiber::start() -> Fiber::suspend() -> Fiber::resume() FiberA FiberB FiberA ``` A -> B -> A This logic remains valid for coroutines as well: ``` Fiber::start() -> Fiber::suspend() -> Fiber::resume() CoroA CoroB CoroA ``` A -> B -> A I hope someone actually read the Fibers RFC, right? > If I'm reading that correctly, it means `span(very_long_function(...))` will > start a coroutine, but not assign it to a variable. > So I cannot track it or refer to it, but it will still run in the background > until it completes, at which point it will get GCed. Is that correct? Yes. The spawn function will return a Coroutine object, which can be used like any other object. The reference count of such an object will be 2. If the result of spawn is not used, the coroutine will live for as long as it is executing. > The FrankenPHP example linked to... doesn't seem to do anything to start a > coroutine. I don't know what it's supposed to be demonstrating other than > FrankenPHP itself. Here, FrankenPHP handles HTTP requests in separate coroutines. That is, it demonstrates how coroutines can help improve performance for a web server. The coroutine is created inside the FrankenPHP extension, and the user provides the request-handling function. Thus, each request is handled in a separate coroutine. > What is the difference then between $coroutine->finally() and > register_shutdown_function(), when the current coroutine happens to be main? There is no difference. Most likely, the finally handler will be invoked before register_shutdown_function, although I am not 100% sure. > Non-Async code can use Cancellation, but... what does that even mean or do? > Why would someone use it? > This is sneaking in a 3rd error type without much guidance. catch(Throwable) > is surprisingly common (rightly or wrongly), so this feels like a major > pothole potential. In this RFC, there is no non-async code. Where does this text come from? > Oh crap, Scopes are now a SEPARATE RFC, of similar length? I thought that when you voted the previous version of the RFC, you had at least read the first page. I see. In fact, the Scope API was separated a long time ago. This was done in order to reduce cognitive load. > This seems mostly logical as a low-level API The term *low-level* is used incorrectly here. *Low-level* is applicable when an API exposes internal implementation details or operates at a lower level of abstraction. For example, drawing a pixel versus drawing a point. Drawing a pixel is low-level. In this case, coroutines themselves (unlike Fibers in the past) are a high-level abstraction that hides all implementation details from the user. If you analyze the API surface of Scope versus this RFC, you will see that the APIs are at the same level of abstraction. Therefore, neither the Scope API nor the Async Base API is low-level. > I want a *safe* API. I am not convinced those are compatible. And I > certainly do not want to see the low-level API in one release and then have > to wait for the next release for the safer API. In programming, the term “safe” is used in different meanings and is usually not applied in the context in which you are using it. I do not recommend using the term **safe** in this case, as the U.S. security services might read this message and ban the use of PHP on the grounds that PHP has no *safe* variables. In this case, the code remains safe even without the Scope API. > Having pipes and PFA in separate releases is bad enough. :-) It was originally assumed that the Scope API, as well as the Context API, would be approved immediately after this RFC. However, given the pace of the discussion, or rather the complete lack of it, this seems unlikely. > That this allows for zombie coroutines or "lost" background coroutines to > exist is, to me, a major problem. You wrote that something is a problem, but you forgot to explain why it is a problem. The Scope API does not prohibit the use of zombie coroutines. > As I've said before, I don't like await, spawn, etc. being free-standing > functions rather than keywords. That is very limiting on the syntax they can > use. It also means, as the examples show, we get this pattern very often: Nevertheless, this is the only reasonable solution for the gradual approval of the API. Moreover, even if keywords are added later, the functions will not need to be removed. > $result = $fn |> spawn(...) |> await(...); (wipes away bloody tears) Oh God, why am I reading this :) A pipe is sequential execution of something. That means if something asynchronous is called inside a pipe, the pipe must wait for it out of the box, without any additional functions. In other words, a “dereferencing” operation of the future must be applied: ```php $result = $data |> strtolower(?) |> spawn(someFunction(...), ?) |> strtoupper(?); ``` I haven’t studied the new syntax yet, but I think the idea is clear. In other words, the pipe must wait for the completion of the asynchronous operation. If PHP can adopt a new, cleaner syntax for closures, then it will be possible to introduce a new spawn keyword for coroutines and create a single, elegant syntax. But in essence, this changes nothing. ---- Ed.
