Hello. > An array_map() always blocks the thread but should never suspend. This function is not related to this discussion or to the RFC.
> Without very clear rules, it becomes impossible to reason about what’ll > suspend and what won’t. As I mentioned earlier, this RFC clearly defines the rules for integrating functions. The functions themselves will be documented. > That’s not quite enough. The order really matters. Different schedulers > produce different observable results. No modern language guarantees a fixed execution order of coroutines. Go, Kotlin, Python, JavaScript, C#, Rust. All only guarantee order when explicit synchronization is used. Everything else is an implementation detail of the scheduler, and user code must not rely on it. (Because concurrency naturally has many valid execution paths, not one. Forcing a single fixed order is impossible without adding heavy synchronization everywhere, which destroys performance and breaks the concurrency model.) > Unfortunately, I can’t find a link to documentation that old. no one can > I may be missing something, but I don’t see this spelled out anywhere in the > RFC. What exactly were you unable to find? > Right now, without suspension rules, scheduler guarantees, defined > syscall-cancellation semantics, it’s tough to evaluate the correctness and > performance implications. > Leaving some of the most important aspects as an "implementation detail" > seems like asking for trouble. I’m sorry, but it’s difficult for me to understand what this is referring to.
