>
> 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 parent-child vs. free model.
This question is what concerns me the most right now.
If you have real examples of how this can cause problems, I would really
appreciate it if you could share them. Code is the best criterion of truth.
>
> You misunderstand:
>
Yes, I misunderstood. It would be interesting to see the code with the
destructor to analyze this approach better.
*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, and this does not concern
user-land. Consequently, the spawn function() code will work everywhere
and always.
2.
I will not base the implementation on Fiber (perhaps only on the
low-level part). Instead of Fiber, there will be a separate class. There
will be no changes to Fiber at all. This decision follows the principle
of Win32 COM/DCOM: old interfaces should never be changed. If an old
interface needs modification, it should be given a new name. This should
have been done from the start.
3.
I am abandoning low-level objects in PHP-land (FiberHandle, SocketHandle
etc). Over time, no one has voted for them, which means they are
unnecessary. There might be a low-level interface for compatibility with
Revolt.
4.
It might be worth restricting microtasks in PHP-land and keeping them
only for C code. This would simplify the interface, but we need to ensure
that it doesn’t cause any issues.
The remaining question on the agenda: deciding which model to choose —
*parent-child* or the *Go-style model*.
Thanks
---
Ed
