I wanted to learn how to make my own plugins so I started with an APT repository proxy plugin which works with the awesome apt-cacher-ng tool, which is something that I wanted for myself.

I’m proud to announce that version 0.1.0 has just been released and is available for download from my development website.

http://dev.funkynerd.com/projects/openmediavault-aptcacher

Sources are available and are released under the GNU/GPL3 licence.

Step one is to get a tunable ECU in and running.  I have gone for a DIYAutotune Microsquirt DIYPNP module, which is actually a great little unit.  Now that I’m getting close to having the ECU in and running, I need to be able to tune it, which requires monitoring the Air/Fuel ratios using a wideband O2 sensor.  My car, as standard, only has a narrowband which just isn’t good enough.  So here’s how to fit an Innovative LC-1 wideband O2 sensor to a 1996 Toyota RAV4.

The new sensor has all been calibrated and tested and working fine.  For now, I’m running one of the outputs in narrowband mode back to the stock ECU.  The second output is in wideband mode and wired up to an unused pin on the 12pin connector for the ECU.  To get the Microsquirt to use that I now just have to re-wire the O2 input to that pin.  Should be a snap.

This is the stock O2 sensor on the exhaust manifold with the heat shield removed.

If you’re pulling out a stock O2 sensor, the trick is to do it while the exhaust is hot.  I now this sounds counter intuitive because you’ll probably burn yourself, it’s a must.  While the exhaust is hot, the metal is expanded and it should be easier to loosen the sensor.  While it’s cold this will be almost impossible without breaking the sensor.  Make sure you protect yourself though.  If you have high-temp gloves, use them.  I didn’t so I just wrapped an old t-shirt around my hand and was extra careful.

Once it’s out, should look like this:

At this point I test fitted the wideband sensor which fortunately fit into the stock bung.  This would have been a deal breaker and I’d be stuck tuning with the narrowband.  This is also why you should be careful pulling out the stock sensor because you never know when you’ll need it again, so breaking it is not cool.

Don’t actually fit the O2 sensor as it needs to stay out for calibration.

Next I mounted the Innovative LC-1 module.  I decided to strap it to the main wiring harness as the cable from the sensor was the perfect length to reach there.  To do this, you should probably pull the battery and battery base panel out.  That just makes it easier to get to.

Here’s the module strapped to the harness

Here it is from the engine side so you can see how tucked away and safe it is:

Next, feed the LC-1 main lead and serial leads through the firewall grommet and into the cabin.

Now, on to wiring up the LC-1 module to the ECU wiring harness.  First, you need to hook up the LED and push button.  These are required for normal operation, but you’d be stupid not to add them in now while you’re at it as they are useful for calibrating and checking status.

Next, ground the system.  This is always the first thing I do and is a good rule of thumb.  If you ground things properly first, then there’s less chance of voltage trying to find another path of least resistance, like your body.  While 12v won’t do anything to a person, this is a rule I live by across the board.

I used the two grounds on pins 13 & 26 of E4 on the ECU connector.  One is slightly thicker, so I used that for the heater ground.

Next I bridged the LC-1 output #1, which is set to narrowband mode by default, to the stock ECU O2 sensor input.

Lastly is a bit of power.  I just bridged the ECU switched 12v.  The current draw shouldn’t be enough to blow the 15A fuse on that line.

Once that’s all hooked up you can turn it on WITHOUT the sensor connected to the LC-1 module.  This forces calibration next time it’s connected.  Let the LED flash for 30 seconds.  Then turn it off, hook up the sensor and turn it back on.  The LED should flash slowly while the sensor warms up, then it will flash faster during heater calibration.  Once the LED lights steady, hold the button for 30 seconds during which the LED will be off.  Release the button and the LED will flick on for a sec, then go off while it’s calibrating.  When it’s all done the LED will light up steady and you’re good to go.

After this I hooked up the serial port and tested the AFRs on the stock ECU.  Currently running about 13.8 at idle which is about right.  Sweet!

I received my USB-Serial cable the other day and I was able to fire up and ECU and load the firmware on to it.  So far it seems to all check out and I’m getting voltage across all circuits.  I then went to plug it into the car and see if I could get some actual sensor readings (it was 9pm so I wasn’t going to try and fire it up).  First two plugs went in fine, but the third plug is wrong.  So much for “plug and play”.  Turns out it’s the usual Toyota bullshit we have to put up with where there are differences between the US and Jap-spec models.  I have a pre-crimped 12-pin plug on the way over from the US that I can splice into the factory harness to fix that though.

Base settings in the ECU are done and I have a pretty generic stoich map set up and ready to go.  The only issues I may have is if I read the wiring diagrams wrong and the VE outputs are hooked up to the wrong pins, or my specs have the wrong injector size and my fuel flow calculations are wrong.  Fingers crossed.

Also, my LC-1 has arrived and will hopefully go into the car in the next week when I get time.  Picked up a second hand one off eBay for $160.  It even has the digital display.  A new LC-1 is usually $199 and with the display $349 so I think I did well considering it’s only been used once.

I’m planning on running the LC-1 narrowband output to the factory O2 pin on the ECU, then running the wideband output to a spare pin on my new plug.  That way I can swap between ECUs easily during the tuning period, in case I need to throw the stocker in and drive it.  I can’t really afford to have it off the road.

Innovative LC-1 Wideband O2 Sensor:

Plenty of silicon vacuum hose for the new MAP sensor:

I’m moving interstate in the next few weeks though so I’m not sure if I will do it before then.  Considering this is the first time I’ve ever tuned an ECU I can’t afford to blow up the motor before the move.  If all goes well and I have absolutely no problems getting it to start and idle ok, then I will probably finish the tune.  First sign of trouble though and it gets shelved until after the move.

More t/k.

So as it turns out, having one modified car is not enough for some people.  Once you get used to power of a single turbo Supra, it’s difficult to settle for anything ‘normal’.  My main issue really is that I hate changing down gears when going up hills.  My daily driver is fine on flat roads but as gutless as on the hills.

With that in mind, I’ve decided that my poor little daily driver is getting a few ‘upgrades’.  So what is my daily?  It’s a 1996 Toyota RAV4 powered by a beasty naturally aspirated 2.0L 3S-FE. The car itself is immaculate inside and out and was a great find 10 months ago when I bought it.

Here’s what it looks like now:

The plan is to turbo-charge the motor and run about 7psi max safely.  Most people think the poor little 3S-FE will pop at 7psi, but others have done it so I’m confident it can handle it.  Things will be happening in two stages.

Stage 1: Prep the fuel system to handle boost.  This means installing a new ECU and wideband O2 sensor for tuning.
Stage 2: Install the turbo, manifold, fuel injectors, etc.

The best part is, I’m hoping to do the whole lot for less than $1500.

Here’s what’s happening:

• Aftermarket MicroSquirt ECU (DIYPNP N76P)
• Innovative LC-1 Wideband O2
• T3 Turbo (‘el Cheapo eBay job) w/ internal WG
• T3 Exhaust Manifold
• Custom dump
• DENSO 320cc Fuel Injectors
• Some random intercooler (still looking for one)

So far I have the ECU built and ready to load firmware onto it.  I’m using the DIYPNP ECU from DiyAutotune.com which comes as a box of parts that you have to solder together yourself.  It took me about 4 hours to solder the mainboard and then about another two to come up with the pinouts and wire them to the board.

This is the state in which the ECU arrived:

Here it is with the mainboard all built and the controller module mounted on top:

Wiring the Denso 76Pin PCB module to the mainboard:

All done and tested with my trusty multi-meter and ready for the lid to go on:

The finished product.  I even bothered to put the sticker on it:

Pinout Wiring maps.  Yay!!:

The pinout wiring map probably took the longest to come up with as like any jap-spec car, documentation on wiring is a bitch to find.  I eventually found a generic 3S-FE engine repair manual in case anyone wants it (PM me).

Now that the ECU is built, I need to load some firmware onto it and do some internal diagnostics to make sure it detects all the circuits I have put on the mainboard (like knock sensor, 3-wire IAC, MAP sensor, etc).

So at this point I’m waiting for the LC-1 and some vacuum hose to arrive so that I can install the sensor and run a hose from the existing MAP sensor to the ECU.  Then it’s just a matter of plugging it in and tuning it.  Once it’s tuned, stage 1 is done and I can start collecting parts for stage 2.

More t/k.

Well, I am. Redmine is still accessible at http://dev.funkynerd.com and hasn’t changed. In a while I will ditch the knowledgebase plug-in, but for now it will stay. All my project management will continue to be done there with no other changes.

In the mean time, I’m still building the theme and layout for this new website so just bare with me.  The articles I’ve got have already been moved across and I’ve got the general layout of menus and other such organisational stuff done.  Hopefully this whole process will make things a bit easier for people to find.

Enjoy!

This class makes use of a fantastically powerful and dangerous ‘magic’ method named __call.   What __call does is allows any inaccessible method to be overloaded.  This means that when you instantiate the class, ANY method that is not accessible in the class will run through the __call method.  Therefore it is possible to use this class to execute methods on the remote application server.

Enjoy

class xmlrpc_client {
	private $url;
	private $proto = 'http';
	private $host;
	private $fhost;
	private $uri = '/';
	private $port = 80;

	private $method_pfx = '';

	private $debug = false;

	function __construct($url, $method_pfx = '', $debug = false){

		$this->method_pfx = $method_pfx;
		$this->debug = $debug;

		if(preg_match('/(\w*):\/\/(.*?)(\/.*)/', $url, $matches)){
			list($this->url, $this->proto, $this->host, $this->uri) = $matches;
			switch($this->proto){
				case 'http':
					$this->port = 80;
					$this->fhost = $this->host;
					break;
				case 'https':
					$this->port = 443;
					$this->fhost = 'ssl://' . $this->host;
					break;
				default:
					$this->dbg("Unknown protocol '$this->proto'.  Defaulting to port $this->port.");
					return;
					break;
			}
			$this->dbg("Correctly parse URL '$this->url'");
		}else{
			$this->dbg("Invalid URL supplied");
			return;
		}
	}

	private function dbg($string, $op_xml = null, $force = false){
		if(!$force && !$this->debug) return;
		echo "
		$string
";
		if($op_xml) echo "$op_xml";
	}

	private function notice($string, $op_xml = false){
		return $this->dbg($string, $op_xml, true);
	}

	public function __call($name, $args){

		if(!$this->fhost && !$this->port && !$this->uri){
			$this->dbg('No host, port or URI has been specified');
			return;
		}

		$method = ($this->method_pfx?$this->method_pfx . '.':'') . $name;
		$response = '';

		$this->dbg("Generating request for method '$method'");

		$output = array('version' => 'xmlrpc');
		$request = xmlrpc_encode_request($method, $args, $output);

		$this->dbg("opening socket to host: $this->fhost, port: $this->port, uri: $this->uri");
		$sck_fd = fsockopen($this->fhost, $this->port, $errno, $errstr, 3);

		if($sck_fd){

			$content_len = strlen($request);

			$http_request =
				"POST $this->url HTTP/1.0\r\n" .
				"User-Agent: xmlrpc-epi-php/0.2 (PHP)\r\n" .
				"Host: $this->host\r\n" .
				"Content-Type: text/xml\r\n" .
				"Content-Length: $content_len\r\n" .
				"\r\n" . $request;

			$this->dbg("Sending HTTP request:", $http_request);

			fputs($sck_fd, $http_request, strlen($http_request));

			$this->dbg('Receiving response');

			$header_parsed = false;

			$line = fgets($sck_fd, 4096);
			while ($line) {
				if(!$header_parsed){
					if($line === "\r\n" || $line === "\n"){
						$this->dbg('Got header:', $header);
						$header_parsed = 1;
					}else{
						$header .= $line;
					}
				}else{
					$response_buf .= $line;
				}
				$line = fgets($sck_fd, 4096);
			}

			fclose($sck_fd);

			$this->dbg('Reponse:', $response_buf);

			$response = xmlrpc_decode($response_buf);

			if((is_array($response)?xmlrpc_is_fault($response):false)){
				$this->notice("Error #$response[faultCode] - $response[faultString]");
				$response = null;
			}

		}else{

			$this->dbg("Unable to open socket.  ERR: $errno# - $errstr");
		}

		return $response;
	}

}

Our Goal

Or goal is simple.  We have some code that we’ve written and we’d like to turn it into a Git repository that is stored on our Git server.  In this example I will be using the procedure I used to add Snippy:http://dev.funkynerd.com/projects/snippy to my public Git server.

Housekeeping

Before we do anything here, there are a few things you may need to get setup first.  You only need to do these once so if you have already done them you can just skip this section

User-based Git Config

It is ALWAYS a good idea to have a .gitconfig file in your home directory (for Linux workstations, obviously).  So, create the file ~/.gitconfig and add at least the following to it.

[user]
name = {your name}
email = you@yourdomain.com

This is used by Git when you commit stuff and makes sure that your commit identity is consistent.  May I also suggest that you do this for everything computer that you expect to commit to git from, regardless of platfrom, and make sure the parameters are consistant.  This will save on some ugliness later.

If you are on Windows, then sorry, I can’t help you right now, but I’m sure you can figure it out.

Create the repository root directory

I keep all my code repositories in /var/local/git.  Here is a listing of how it looks:

drwxr-sr-x 7 root staff 4096 2011-02-01 11:41 git

As you can see, I have added the directory to the _staff_ group and make the group sticky.  This means that anything created under that directory will have the default group of staff.  Make sure your Git repository directory is setup like this.

To get the directory created just do the following:

$ sudo mkdir /var/local/git
$ sudo chgrp staff /var/local/git
$ sudo chmod g+ws /var/local/git

That’s all there is to it.  Now we have a nice place to start adding our repositories.

Initialise the local repository

Basically all we need to do is change to the directory where our code is, create an empty Git repository and make our initial commit.

$ cd /usr/src/snippy
$ git init
Initialized empty Git repository in /usr/src/snippy/.git/
$ git add *
$ git commit

When prompted, add your initial commit message (I usually just put “Initial commit of {project name}”).  You now have a populated local repository that you can use “as is” to manage your code.  Even if you choose not to make it public now, you can do so later at any time by just continuing on with the below steps.

Create a public repository

This bit is the most complicated part due to the permissions required to allow write access to certain users.  Hopefully the steps below make it a bit easier to follow.

Here’s how you create the repository and set the permissions up to allow write access.

$ sudo git init --bare /var/local/git/snippy.git
Initialized empty Git repository in /var/local/git/snippy.git/
$ sudo chmod -R g+w /var/local/git/snippy.git
$ sudo touch /var/local/git/snippy.git/git-daemon-export-ok

Note: The git-daemon-export-ok is required to allow the git-daemon to export the repository.  If this file does not exist, the git-daemon will not export it.

That’s it.  Now you just need to make sure that anyone you want to allow access to write to your repository is a member of the staff group.

Making our repository public

This step involves setting up our local repository with the location of our previously created public repository and pushing our commit out to it.

Setting up

When we initialised the local repository, Git created a hidden sub-directory called .git.  In there is a file called config that we need to edit.

Mine looks like this:

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git://dev.funkynerd.com/snippy.git
[branch "master"]
remote = origin
merge = refs/heads/master
[remote "pub"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = ssh://dev.funkynerd.com/var/local/git/snippy.git
push = refs/heads/master:refs/heads/master

The [remote "origin"] section defines a remote repository that we can fetch from.  The [branch "master"] section tells git that master is a remote branch located on the *origin* server which is where we want to get our sourcecode from when we issue a *pull* command with no repository specified.  Finally, [remote "pub"] defines a remote repository that we can write to for push commands.  Notice that this uses ssh instead of git.  This is because git does not allow writing.  This is also so that git can make use of ssh’s security functions.  So if you can ssh to the server with a shared key, then you can push your git repository.  If you don’t use a shared key then you can still use a password if your ssh server allows it.

Making the push

Lastly, all we need to do is push our local repository to the public one.

$ git pull
$ git push pub
Counting objects: 160, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (152/152), done.
Writing objects: 100% (160/160), 293.01 KiB, done.
Total 160 (delta 26), reused 0 (delta 0)
To ssh://dev.funkynerd.com/var/local/git/snippy.git
* [new branch]      master -> master

If you see something like the above then you’re good to go.  For good measure it always recommended that you issue a git pull once you’ve done a push, just to make sure everything is in sync.

This time, you should get the following:

$ git pull
Already up-to-date.

You’re now good to go.

On-going usage

While you continue to develop just be aware that there may be others pushing changes to the public repository.  Git is pretty good at getting the right changes in without messing up things but there are some good practices to keep in mind that help minimise the chance of something getting screwed up.

Before you push, do a pull.

$git add
$git commit
$ git pull
Already up-to-date.
$ git push pub

You may not always be up to date and some changed may come down.  Most of the time they will just get merged in without a problem.  Sometimes there will be conflicts which Git will guide you through resolving at this point.

When you’ve pushed, do another pull

$ git push
$ git pull
Already up-to-date.

This just keeps everything in sync.  See, when you push stuff to the remote repository that push is also tracked as a commit and has a commit ID.  It’s wise to do a pull straight away so that those commits are also known in your local respository.  Really, it would be nice if a push implied a pull because 99.9% of the time you do this.  But the coolness of Git is that it caters for all situation, including the 0.01% of the time you don’t want to pull straight away.

This article assumes that you have a fully function installation of Redmine and know how to install plugins.  If now, the “redmine plugins”:http://www.redmine.org/projects/redmine/wiki/Plugins page is a good place to start.

Gitosis

The first thing we need to do is install Gitosis and get that up and running.  It can be a little tricky when you don’t know how it works and it took me a while to figure it out, so I’ll try and explain it here using my limited knowledge.

A quick and nasty intro to Gitosis

Gitosis is a bunch of scripts that work with a central “gitosis-admin” repository.  Users interact with git repositories as a single user and access is controlled by Gitosis.  To add repositories, you clone the gitosis-admin repo, edit the config file, and export that back to the public repo.  At this point, a post-commit hoot script is executed which “does stuff”.  This is essentially how Gitosis works.  Then you can commit to the admin repo the script runs which sets things up.  You don’t really need to know much more than that.

Installing Gitosis

I use Ubuntu (and so should you be) so I’m only going to go into installing it on Ubuntu here.  There is already a tonne of documentation on how to install it from the Gitosis repository on github.  Use Google.  Or if you’re lazy, just “go here”:https://github.com/res0nat0r/gitosis.

The steps involved are pretty much install it from APT, then initialise it with your public key.  Just two steps.  It couldn’t be easier.

First, you MUST create a public/private key pair that is unique to Gitosis.  You *CANNOT* use your public key as this will cause problems later down the track when you start committing things to your project repositories.  The reason I’m making a big deal about this is because it caught me out.  Most of the documentation out there for installing Gitosis refers to using your own _id_rsa_ private key file.  Don’t.  You need your own key later and it needs to be unique or this wont work.

I just did the following:

$ cd /tmp
$ ssh-keygen -t rsa -f redmine_key

This will create two files in _/tmp_ called *redmine_key* and *redmine_key.pub* which are your private key and public key respectively.

Now to install Gitosis:

$ sudo apt-get install gitosis
$ sudo -H -u gitosis gitosis-init < /tmp/redmine_key.pub

In the second command, the _-H_ is absolutely necessary as the script uses the $HOME environment variable which is only set correctly with the _-H_ parameter.  When you run the gitosis-init command, you should see the following if it’s successful:

Initialized empty Git repository in /srv/gitosis/repositories/gitosis-admin.git/
Reinitialized existing Git repository in /srv/gitosis/repositories/gitosis-admin.git/

At this point, Gitosis is installed and ready to go.  But, to make sure you are going to test it, right?  Let’s do that.

Normally at this point you would create a test project to test the gitosis install but seeing as we are using a separate unique private key, we can’t.  Trust me though.  If you’ve gotten this far without error, it will work.

Install the Gitosis Redmine plugin

Up until now, you’ve been doing stuff that is pretty easy and common to all Gitosis installs.  The next part takes some work because the plugin itself while good when it’s working, *WILL NOT* work out of the box.  That is, you need to make a few changes to get it working AT ALL.  A lot of the changes are to fix silly bugs that the author has not bothered to fix as yet.

So, here we go.

Install

This part is common to all Redmine plugins, and this one is no different.  You _should_ know how to do this.  Just remember to replace _/usr/share/redmine_ with wherever your version of Redmine is installed.

As your redmine user, do the following to install the plugin:

$ cd /usr/share/redmine
$ script/plugin install git://github.com/rocket-rentals/redmine-gitosis.git
$ cd vendor/plugins
$ mv redmine-gitosis redmine_gitosis

Now we need to fix up the database definition and a tiny little bit of code to make it all work correctly.  See, the problem is that the code refers to a field in the database as an integer, but in the database it’s a boolean.  This is wrong and wont work.  So we need to update the database definition to create the field as an integer instead, then fix the one place that it actually does refer to it as a boolean.  Blah.  What a pain.

Fix the plugin

From the plugins directory (you should be in it), edit _redmine_gitosis/db/migrate/20091119162427_create_gitosis_public_keys.rb_ (the number _may_ be different, but you’ll find it) and change this:

t.column :active, :boolean, :default => true

to this:

t.column :active, :integer, :default => 1

It should be about the 7th line down and quite easy to find.

Now, edit _redmine_gitosis/app/helpers/gitosis_public_keys_helper.rb_ and change the only two lines with true and false in the from this:

["#{l(:status_active)} (#{key_count_by_active[true].to_i})", GitosisPublicKey::STATUS_ACTIVE],
["#{l(:status_locked)} (#{key_count_by_active[false].to_i})", GitosisPublicKey::STATUS_LOCKED]], selected)

to this:

["#{l(:status_active)} (#{key_count_by_active[1].to_i})", GitosisPublicKey::STATUS_ACTIVE],
["#{l(:status_locked)} (#{key_count_by_active[0].to_i})", GitosisPublicKey::STATUS_LOCKED]], selected)

Migrate (create the database stuff)

Now we can migrate the plugin as normal:

$ rake db:migrate:plugins RAILS_ENV=production

Configure the plugin

Before we can start using the plugin, we need to make sure it knows how to talk to Gitosis.  The defaults will most likely NOT work.

This is the setup for Ubuntu.  But if you’re not on Ubuntu you should know what to replace by now.  Just edit _redmine_gitosis/lib/gitosis.rb_ and set:

# server config
GITOSIS_URI = 'gitosis@www.funkynerd.com:gitosis-admin.git'
GITOSIS_BASE_PATH = '/srv/gitosis/repositories/'

The last thing we need to do is add the private key for Gitosis to the plugin.  We created this waaay back in the first step, but it should still be there.  Redmine keeps it’s private key in _{plugins_dir}/redmine_gitosis/extras/ssh/private_key_, so just do this:

$ cp /tmp/redmine_key /usr/share/redmine/vendor/plugins/redmine_gitosis/extra/ssh/private_key

Now you can restart you Redmine server.  For me that’s just:

$ sudo /etc/init.d/apache2 reload

Using the plugin

Everything is installed and should be ready to go and the plugin should be running in Redmine.  There is one final config option we need to do for your Redmine user account.

Add your public key to your account

From the Redmine interface, click on “My Account” to access your account page.  You should now see a link that says _Public Keys_, probably on the top right of the page (depends on your Redmine theme).  Click through to the Public Keys page and we can add your public key by clicking on _New Value_.

The page that comes up should look like this:

Just give it a name and paste in the contents of your _~/.ssh/id_rsa.pub_ file.

Now you can add repositories to projects as you would normally.  Instead of specifying where the repo is located though, the plugin just creates it in the background.

Committing code to the repo

To commit your code you can do the following from your projects source dir (assuming it is not already a local git repo):

$ git init
$ git remote add origin gitosis@your.servername.com:projectname.git
$ git add *
$ git push origin master

Hopefully that will commit correctly and you can go back to hacking you code.

Therefore I decided to take it upon myself to write a PHP thread class that makes use of the PHP process control functions.

In the end the class turned out to be quite simple, so I can’t believe this hasn’t been done before (according to Google anyway).  It’s been a while since I wrote or used this, so if anyone has any questions feel free to post a comment and I’ll do my best to answer them.

And without further ado, here’s the code:

class Thread {

    private $pref;          // Process reference
    private $pipes;         // STDIO
    private $buffer;        // Output buffer
    private $start;         // Execute start time

    private function Thread() {
        $this->pref = 0;
        $this->buffer = "";
        $this->pipes = (array)NULL;
        $this->start = time();
    }

    public static function Create( $file, $stderr = null ){

        if( ! $stderr ) $stderr = array( "pipe", "w" );

        $t = new Thread;
        $descriptor = array( 0 => array( "pipe", "r" ), 1 => array( "pipe", "w" ), 2 => $stderr );
        $t->pref = proc_open( "php -q $file ", $descriptor, $t->pipes );
        stream_set_blocking( $t->pipes[1], 0 );

        return $t;
    }

    public function isActive(){
        $this->buffer .= $this->listen();
        $f = stream_get_meta_data( $this->pipes[1] );
        return !$f["eof"];
    }

    public function Close(){
        $r = proc_close( $this->pref );
        $this->pref = NULL;
        return $r;
    }

    public function Tell( $thought ) {
        fwrite( $this->pipes[0], $thought );
    }

    public function Listen(){
        $buffer = $this->buffer;
        $this->buffer = "";
        while( $r = fgets( $this->pipes[1], 1024 ) ){
            $buffer .= $r;
        }
        return $buffer;
    }

    public function getError(){
        $buffer = "";
        while( $r = fgets( $this->pipes[2], 1024 ) ){
            $buffer .= $r;
        }
        return $buffer;
    }

    public function getStartTime(){
        return $this->start;
    }

    public function getRunTime(){
        return ( time() - $this->start );
    }
}

How it works is quite simple. From your parent thread, use the Thread::Create( file.php ) method to create a new Thread object.  The code in file.php should be a whole, executable PHP program.  You can use the Thread::Tell() to send data to the threads STDIN stream and Thread::Listen() to read data from the threads STDOUT stream.  Ideally I should have written another class to handle IO inside the thread itself but my ‘worker thread’ code uses stream_select to read strings from STDIN and then fwrite to send data back to STDOUT and the parent process.

This isn’t ideal, but it works quite well and has been running flawlessly in a production environment for 2 years now.

Basic Example

$thread = Thread::Create( 'test.php' );

$thread->Tell('DOSTUFF');

while(true){
    $ret = $thread->Listen();
    if( $ret == 'DOINGSTUFF' ){
        break;
    }
}

$thread->close();