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.s...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php