Hello PHP folks,
I've seen this discussed previously, and would like to add a few
arguments for the multi-threading side vs. async processing,
which I've seen mentioned as a viable alternative:
1. Imagine that from time to time, some background processing takes 1
second of CPU time - w/o multithreading, all your async operations,
like accepting a connection to a socket, aio or others are basically
stalled. So, async is a good approach, but does not work as a magic
wand for all problem spaces. Alternatively, you could fork and then do the
processing, but then the state syncing of the forked background processing
results with the main thread requires a whole new protocol / switching to
interprocess communication, which makes such developments unnecessarily
hard. Threads exist for a _reason_ not only because they sound cool.
2. Without thread support, it is not possible to use multi-core processing
paradigms directly from PHP - which means PHP relies on external
frameworks for
that feature, which, in a sense, makes it a non-general-purpose language.
It _could become_ a general purpouse tool, if it had proper
multi-threading
support built-in.
I, personally, considered developing websockets / nanoserv server stack
with PHP
and bumped into the multithreading limitation - AFAIK it is the only big
feature
separating PHP from the general purpouse languages. Everything else is
well
integrated with lots of external libraries/modules giving rise to
potential rapid
application development while using it.
Cheers and let me know about your thoughts, and potential core
implementation
issues regarding developing this language feature.
--
Best regards,
speedy mailto:[email protected]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
