php and multithreading (additional arguments)
| From: | speedy | Date: | Thu, 01 Apr 2010 14:32:15 +0000 |
| Subject: | php and multithreading (additional arguments) | ||
| Groups: | php.internals | ||
| Request: | Send a blank email to internals+get-47701@lists.php.net to get a copy of this message | ||
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:speedy.spam@gmail.com