Exploring Coroutines in PHP
doeken.org
Exploring Coroutines in PHP
1–10 of 68 posts
Re: Exploring Coroutines in PHP
#2[deleted]
Re: Exploring Coroutines in PHP
#3>> This would require a yield to syntax, which doesn't exist.
There is however the 'yield from' statement.
Re: Exploring Coroutines in PHP
#4I don't write PHP code anymore. I had a great time doing so for years but now I mostly write in Go for a company that writes a lot in PHP.
What I see from PHP is a missed opportunity for not having any native lightweight multi thread capabilities not a robust HTTP server.
I wish the situation changed.
Re: Exploring Coroutines in PHP
#5I don't write PHP code anymore. I had a great time doing so for years but now I mostly write in Go for a company that writes a lot in PHP. What I see from PHP is a missed opportunity for not having any native lightweight multi thread capabilities not a robust HTTP server. I wish the situation changed.
My hope is that the parallel extension will get more widespread adoption when its integrated into FrankenPHP: https://github.com/krakjoe/parallel
Re: Exploring Coroutines in PHP
#6I don't write PHP code anymore. I had a great time doing so for years but now I mostly write in Go for a company that writes a lot in PHP. What I see from PHP is a missed opportunity for not having any native lightweight multi thread capabilities not a robust HTTP server. I wish the situation changed.
I work daily with PHP and honestly nearly all my code I write is synchronous.
The shared-nothing architecture of PHP makes that really a non-issue for me. Requests never share any state with each other. Something like RabbitMQ can handle communication between systems.
Re: Exploring Coroutines in PHP
#7I have read much about Fibers since they were introduced and have never come up with a real use case.
All the examples I find are like the trivial ones here where it just feels like instead of jamming a bunch of code into a single messy function that yields, you'd be better off particularly from a static analysis standpoint just having ordered method calls or chained callables where each step returns the next step as a callable.
I've yet to see a use case where I can't come up with a safer way to do it without Fibers, but I would love if someone could enlighten me because I feel like I am absolutely missing something.
Re: Exploring Coroutines in PHP
#8I think neither does PHP have the ecosystem for it, nor does it have the language primitives or standard library for it. Much cleaner languages than PHP already have enough issues getting concurrency things like fibers right. I don't see this ending in any implementation, that doesn't have surprising dysfunctional parts in it. Especially not, when again and again people behind PHP chose the easy way out for adding language features, like they did with lambdas, that don't capture their environment, unless you explicitly state what they capture.
Let alone the standard library being an unfixable mess, if they want to pursue backwards compatibility. What they would need to do is a clean break. Something like "PHP 10 is a breaking change, we are modernizing the base language and standard library and getting rid of decades of cruft." -- Which then many PHP users would hate.
No, PHP is a not a language whose design has what it takes. A library that claims to have such advanced stuff implemented in PHP is not to be easily trusted to be free of hassle and tripwire, because the language itself has those built-in. For example with Fibers, one has to manually call suspend and resume. Other languages get fibers done without this hassle.
EDIT: For all the downvoters, who don't care to actually give reasons or discuss, the cracks are already showing in the Fibers manual itself. Look at the first comment for example: https://www.php.net/manual/en/language.fibers.php#127282 which links to a bug/issue in the Fibers repo. It is a bug, even recognized via issue label, it is verified, as recognized via issue label, and it is ... closed. Apparently it will not be fixed, and has been simply closed.
Re: Exploring Coroutines in PHP
#9I don't write PHP code anymore. I had a great time doing so for years but now I mostly write in Go for a company that writes a lot in PHP. What I see from PHP is a missed opportunity for not having any native lightweight multi thread capabilities not a robust HTTP server. I wish the situation changed.
My hope is that the parallel extension will get more widespread adoption when its integrated into FrankenPHP: https://github.com/krakjoe/parallel
I still have flashbacks from working with the pthreads extension, which caused extremely hard to debug, non-reproducible segfaults sometimes; I realise Joe has probably started from scratch and improved a lot on that (and I know he's a generally awesome guy), but without a properly financed maintainer team to support him, I'm not sure I want to take that risk again before parallel has gained some maturity.
Re: Exploring Coroutines in PHP
#10I don't write PHP code anymore. I had a great time doing so for years but now I mostly write in Go for a company that writes a lot in PHP. What I see from PHP is a missed opportunity for not having any native lightweight multi thread capabilities not a robust HTTP server. I wish the situation changed.
I work daily with PHP and honestly nearly all my code I write is synchronous. The shared-nothing architecture of PHP makes that really a non-issue for me. Requests never share any state with each other. Something like RabbitMQ can handle communication between systems.
That's in no way lightweight though, and most languages can easily do the same. Just launch multiple instances/VMs/processes. That's having multiple separate OS processes, each having everything that is needed to run PHP, and having no way to communicate with each other, other than what you implement. No channels, no task distribution, no queue on which to sync and take tasks from, no signaling of all processes being done and then accumulating the results. That is why you then need something like RabbitMQ or other things, and it does not mitigate the heaviness of the approach.
It is kinda funny, that you mention RabbitMQ, which is written in Erlang, which is famous for its lightweight processes. But also compare the approach with thread pools built into the standard libraries in other languages. And even many of those are heavy weight compared to Erlang's lightweight processes.