Re: php and multithreading (additional arguments)

I used to play with TSRM days ago and successfully implemented userland threading support using GNU Pth. It's just a proof of concept and I did it for fun. If interested, check out http://github.com/moriyoshi/php-src/tree/PHP_5_3-threading/ and read http://github.com/moriyoshi/php-src/blob/PHP_5_3-threading/ext/threading/README for detail (not much information though). Also note that the language syntax was extended there so it would support golang-like message passing. <?php function sub($i, $ch) { for (;;) { // receive the message from $ch $a = <- [$ch]; printf("%d: %s\n", $i, $a); } } $ch = thread_message_queue_create(); for ($i = 0; $i < 10; $i++) { thread_create('sub', $i, $ch); } $i = 0; for (;;) { // send $i to $ch [$ch] <- $i++; usleep(50000); } ?> Moriyoshi On Thu, Apr 1, 2010 at 11:32 PM, speedy <speedy.spam@gmail.com> wrote: > 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 > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >