5 ms·

Thread class for multithreading in PHP

9 points by fosk 16y ago

pilif 16y ago
This is not about multithreading, but about using multiple processes for parallelization. As such, both the library and the title of this article are misnamed. Still. Having a simple library to do the fork dance and provide some synchronization between subprocesses can be very helpful for, say, long-running import scripts. At least that's what I actually consider using this for.
birken 16y ago
I can't say this makes a lot of sense to me. If you want an interpreted language that has great threading or multiprocess support, I don't know why you wouldn't use Python or Ruby. PHP certainly offers some solid functionality in a lot of places that are very common for web apps, but this is a stretch. A good engineer uses the right tool for the job, no use in fitting a square peg in a round hole.
- z92 16y ago
  Some people don't search for languages that have threading or multiprocess support, rather simply want the language of their choice to have threading and multiprocess support. This is good news for them nevertheless.
- pilif 16y ago
  To expand on z92's answer: In my case, I have a huge web application including a ton of framework code that's powering a frontend. In the backend, there are scripts processing many millions of rows each day. These scripts depend on the framework being available (for example to do certain tasks in the context of a specific user, or just for configuration settings). It's infinitely more useful to be able to actually rely on that framework in these scripts than having to recreate all the environment (or the needed parts of it) every time - especially as the framework might change and the scripts should continue to work. This makes these scripts prime candidates to be written in the same language as the web frontend and the framework, which, unfortunately, means PHP. By being able to easily spawn a few subprocesses from these scripts, I can make them a lot faster while still being able to rely on the standard application environment to be there for them.
dhotson 16y ago
Neato! :-) I had a go at this a while ago using pcntl_fork() and shared memory messages queues to do erlang style message passing. My implementation is kind of half assed, but it works reasonably well. http://github.com/dhotson/Phork http://github.com/dhotson/Phork
yuvadam 16y ago
Important thing to note. This Thread.php implementation works using pcntl_fork(). The biggest gotcha - pcntl_fork() is not supported under Apache. Basically rendering the whole thing rather useless for most use cases.

9 points by fosk 16y ago

pilif 16y ago

This is not about multithreading, but about using multiple processes for parallelization. As such, both the library and the title of this article are misnamed. Still. Having a simple library to do the fork dance and provide some synchronization between subprocesses can be very helpful for, say, long-running import scripts. At least that's what I actually consider using this for.

birken 16y ago

I can't say this makes a lot of sense to me. If you want an interpreted language that has great threading or multiprocess support, I don't know why you wouldn't use Python or Ruby. PHP certainly offers some solid functionality in a lot of places that are very common for web apps, but this is a stretch. A good engineer uses the right tool for the job, no use in fitting a square peg in a round hole.

z92 16y ago
Some people don't search for languages that have threading or multiprocess support, rather simply want the language of their choice to have threading and multiprocess support. This is good news for them nevertheless.
pilif 16y ago
To expand on z92's answer: In my case, I have a huge web application including a ton of framework code that's powering a frontend. In the backend, there are scripts processing many millions of rows each day. These scripts depend on the framework being available (for example to do certain tasks in the context of a specific user, or just for configuration settings). It's infinitely more useful to be able to actually rely on that framework in these scripts than having to recreate all the environment (or the needed parts of it) every time - especially as the framework might change and the scripts should continue to work. This makes these scripts prime candidates to be written in the same language as the web frontend and the framework, which, unfortunately, means PHP. By being able to easily spawn a few subprocesses from these scripts, I can make them a lot faster while still being able to rely on the standard application environment to be there for them.

dhotson 16y ago

Neato! :-) I had a go at this a while ago using pcntl_fork() and shared memory messages queues to do erlang style message passing. My implementation is kind of half assed, but it works reasonably well. http://github.com/dhotson/Phork http://github.com/dhotson/Phork

yuvadam 16y ago

Important thing to note. This Thread.php implementation works using pcntl_fork(). The biggest gotcha - pcntl_fork() is not supported under Apache. Basically rendering the whole thing rather useless for most use cases.