# [VOTE] Fiber API - Thread: https://externals.io/message/102214 - Original archive: https://news-web.php.net/php.internals/102214 - Started by Haitao Lv on 2018-06-10T12:09:13+00:00 - Messages: 7 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #102214 — Haitao Lv — 2018-06-10T12:09:13+00:00 URL: https://externals.io/message/102214#102214 Hello Internals, The RFC for fiber is now open for a vote. The RFC is available at https://wiki.php.net/rfc/fiber. Voting will be open until June 22th, 2018. Thank you. --- ## #102215 — Niklas Keller — 2018-06-10T12:50:42+00:00 URL: https://externals.io/message/102214#102215 · In reply to: #102214 Hey Haitao, there doesn't seem to be any voting snipped on that page, so there's no actual vote yet. Also, the open issues section should usually be empty when the vote starts. The implementation in its current state is very limited and not really useful to real-world applications. Written code can't even be tested with common testing tools such as PHPUnit, because PHPUnit relies on reflection, which is unsupported by the current RFC. Additionally, the "why not as extension" doesn't really have a good reasoning. In its current state, I think it's better suited as an external extension. I'd really like to get fibers into PHP, but not in that state, sorry. Regards, Niklas --- ## #102218 — Joe Watkins — 2018-06-10T19:08:27+00:00 URL: https://externals.io/message/102214#102218 · In reply to: #102214 This is not ready for voting, please stop the vote. Bringing stuff to vote that is incomplete, where there is no clear consensus, is dangerous. > Hello Internals, > > The RFC for fiber is now open for a vote. The RFC is available at > https://wiki.php.net/rfc/fiber. > > Voting will be open until June 22th, 2018. > > Thank you. --- ## #102221 — Levi Morrison — 2018-06-11T00:17:19+00:00 URL: https://externals.io/message/102214#102221 · In reply to: #102218 Replying to Joe's email because I didn't get the original. > > This is not ready for voting, please stop the vote. > > Bringing stuff to vote that is incomplete, where there is no clear > consensus, is dangerous. > > > > > > […] I don't think I've listed my complaints yet although I believe others already covered these: 1. I don't like `Fiber::` referring to the fiber running. I would prefer it being passed as a parameter. 2. As written and implemented this is not sufficiently different from generators. If fibers supported suspending/resuming C code as well then it may be powerful enough to justify it, however... 3. I don't feel this low-level building block is proven. Theoretically we should be able to build async/await functionality with it, which is I believe is the real goal. However, until I've seen it built, demonstrated, and critiqued I don't think we can claim the the low-level building block is sound. Sorry for not providing feedback sooner. Levi Morrison --- ## #102231 — Joe Watkins — 2018-06-12T07:43:42+00:00 URL: https://externals.io/message/102214#102231 · In reply to: #102221 Morning, I waited for a day for you to take action, you failed to do that. To protect PHP, and your idea, I have moved the RFC back to discussion, I would rather you had done that yourself. Please do not attempt to bring this topic to vote until outstanding issues are resolved, and until there is a clear consensus about the implementation we are going to use. Cheres Joe > Replying to Joe's email because I didn't get the original. > > > > […] > > I don't think I've listed my complaints yet although I believe others > already covered these: > > 1. I don't like `Fiber::` referring to the fiber running. I would > prefer it being passed as a parameter. > 2. As written and implemented this is not sufficiently different > from generators. If fibers supported suspending/resuming C code as > well then it may be powerful enough to justify it, however... > 3. I don't feel this low-level building block is proven. > Theoretically we should be able to build async/await functionality > with it, which is I believe is the real goal. However, until I've seen > it built, demonstrated, and critiqued I don't think we can claim the > the low-level building block is sound. > > Sorry for not providing feedback sooner. > > Levi Morrison --- ## #102242 — S.A.N — 2018-06-12T23:13:43+00:00 URL: https://externals.io/message/102214#102242 · In reply to: #102231 Maybe someone can help in the finalization Fiber. Haitao Lv, in pull request asked for help from Dmitry Stogov and Nikita Popov, but no one answered him. https://github.com/php/php-src/pull/3203 All popular web programming languages (JavaScript, Python, Ruby, Lua, etc..) already implement userland async runtime. Thanks. --- ## #102290 — shinji igarashi — 2018-06-18T00:38:44+00:00 URL: https://externals.io/message/102214#102290 · In reply to: #102242 Hello, I'm a fan of this RFC. It seems that there is no time to finalize this RFC during the alpha stage. Maybe the true voting will be postponed to the next version, if no more works are made within a few days. Haitao, do you still have the motivation to bring this into core? If you have no time to brush up the RFC (in english...), how about committing the RFC text into a repository? There are some people supporting the concept itself. Maybe they can help you to make the RFC more presentable by sending PR. Or, if you don't have reason to continue the RFC anymore, then say so... Someone can continue your work. Even if there are people supporting the concept, the current choice of implementation seems to be disliked. Haitao, why do you stick to the way switching VM stack only? Yes, the way switching also machine (C) stack would increase memory consumption. But, to borrow your expression, Ruby's Fiber uses this method. Ruby switches both VM stack and machine stack in its implementation of Fiber. If yielding from internal callback is important to pass the voting phase, I think the machine stack switching should be considered more seriously. The machine stack switching also has its own issues to be solved. - Measuring stack consumptions in real world applications. - Finding reasonable excuses for lacking portablity. (Is this acceptable to core feature or bundled extension?) - Still no sufficient explanations bringing it into core, even if above problems are cleared. I want to see the future that traditional ordinal PHP library is asynchronized reasonably with this kind of feature, like this interesting work. https://github.com/joelwurtz/doctrine-async Cheers, Shinji IGARASHI 2018/06/13 午前8:14 "S.A.N" : Maybe someone can help in the finalization Fiber. Haitao Lv, in pull request asked for help from Dmitry Stogov and Nikita Popov, but no one answered him. https://github.com/php/php-src/pull/3203 All popular web programming languages (JavaScript, Python, Ruby, Lua, etc..) already implement userland async runtime. Thanks.