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.
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
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.
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.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.
I don't think I've listed my complaints yet although I believe others
already covered these:
- I don't like
Fiber::referring to the fiber running. I would
prefer it being passed as a parameter. - 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... - 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
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.
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.
I don't think I've listed my complaints yet although I believe others
already covered these:
- I don't like
Fiber::referring to the fiber running. I would
prefer it being passed as a parameter.- 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...- 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
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.
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" ua.san.alex@gmail.com:
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.