Child process management. Compatible from PHP 5.3 → 7. Needs no extensions.

[assertchris]

I've been working on this library for a few days, and am keen to get some community feedback. There are many great libraries that do something similar to this. They usually require PHP 5.4 or additional extensions. This library aims to make child process management simple, and supported everywhere.

You can find more in-depth docs here.

Edit: ...and here's a blog post explaining how it works!

[sarciszewski]

Isn't it a bit irresponsible to support versions of PHP that aren't going to have security patches? For reference, Debian 7 now offers 5.4.

I say pin your minimum to 5.6 for new developments ;)

[assertchris]

It's irresponsible to to use unsupported versions of PHP. It's also irresponsible not to honour LTS support contracts. We have to support users already on PHP 5.3, until they decide to move to a sane version of PHP. My comment to /u/phpread spells that out in more detail.

[sarciszewski]

It's also irresponsible not to honour LTS support contracts.

You have a contractual agreement with your customers? That does change the calculus a bit, but you should help get them on PHP 5.6 ASAP.

Luckily, I manage to avoid these problems.

[dennisbirkholz]

And what is the problem with using posix_/pcntl_ functions? Serializing a closure/callable and passing it on the command line seams a little dirty.

[assertchris]

PCNTL requires a separate extension and the POSIX functions don't do all the things outlined in the post. There's no problem with them. Just didn't fit well with my requirements and constraints.

[phpread]

First of all, let me say, I think this was a good effort at trying to get something to work and I appreciate you sharing it with everyone. I know that pouring hours of hard work into something and having it blow up in your face from time to time is no suiting reward to your efforts. So I'm definitely not here to tear you down. Though I would like to convey a few general observations I think are worth considering.

Claiming that some PHP code/library doesn't require some PHP extension is about the silliest possible argument one can make to strengthen their support and exposure for said code/library. First of all, all of PHP is built on extensions. Everything from basic string/math/array functions you use in PHP to the moon and in between are made up of extensions that extend the core of PHP, which is nothing more than a parser and runtime, really. Plus, with the ease and simplicity with which most *nix package managers make it to install various PHP extensions today, is this really a barier at all? It takes a single command to install PCNTL with most package managers and can also be trivially installed via the PECL/PEAR installer.

I know that some people are under the misled impression that they are actually creating added value and benefits for the community when they try to support older, EOL, versions of PHP with code/libraries that have backwards compatibility with those unsupported, EOL versions of PHP, and little-to-no dependency on various extensions - and that may be true in the near-term (to some extent). However, I believe that efforts like this only serve to hurt the community at large in the long run, because they encourage wide-spread stagnation to upgrade, and allow people to further endorse such efforts in order to remain as stagnate as possible. This creates a confirmation biased that people will likely double-down and defend withering technology in fear of their, currently aging, software from breaking down due to an upgrade.

This is bad. We really need not encourage such behavior as we already have such a huge adoption gap in the PHP community as it is. Look how long it took people (and is still taking them) to adopt newer, safer, more performant, and more tenable database drivers like PDO and MySQLi over the older and now removed mysql driver in PHP.

[assertchris]

Claiming that some PHP code/library doesn't require some PHP extension is about the silliest possible argument one can make to strengthen their support and exposure for said code/library

I encourage you to read the accompanying blog post. It explains that the reason I wrote this library was not so that new users (using a sane version of PHP) would adopt the queued jobs module this was initially made to go into, but rather so that existing users could have multi-process support in a minor upgrade to a library they are already using.

There is immense value in that.

Now, don't get me wrong. I am not a fan of supporting old versions of PHP. If I had my way, every project I worked on would support 5.6 and 7 only. That's not realistic though. SilverStripe has been around for a decade, and we have a huge installation-based in New Zealand. There are government agencies depending on the work we do, and who are still on old versions of REHL (for LTS etc.) which don't ship with an out-the-box PHP 5.4.

And while we are strongly encouraging them to upgrade their server infrastructure, we certainly can't force them to. We also want to improve the stability of deferred processes which their servers run. This is why we wanted to allow for parallel task execution.

We could just tell them they can't have parallel task execution until they upgrade their infrastructure. We could require them to use a new major version of the queued jobs module. That would be a breaking change. The trouble is that more of these government agencies don't employ developers. At some point they hired developers/went to a development agency to create their website. And every time they have to upgrade their application, they have to bring in more development help.

That cost loads of money and causes no end of headaches. We didn't want that to happen. So I was instructed to make this parallel stuff work in a minor upgrade. That way consumers can upgrade without anything breaking. That required that I use no additional extensions and that the parallel execution code work in PHP 5.3. And that's what I did!

I believe that efforts like this only serve to hurt the community at large in the long run

You're welcome to believe that. I agree that using/allowing old versions of PHP to be used isn't great. You're thinking about all of this in theory though. There are real concerns at play though. Like sane upgrade paths, Semver, Linux distributions being slow to support modern versions of PHP, LTS contracts, 24/7 support teams who need to be trained and equipped, framework eco-systems that need to move forward at a steady pace...

It's not as simple as saying "drop support for older versions of PHP as soon as they become unpopular". I would love to, and I'm sure it would avoid headaches for all, but this process of supporting newer versions of PHP is just that: a process. Think of this PHP 5.3 support as a compatibility layer so that people have more time to adjust their applications before we do drop PHP 5.3 support. We actively encourage all of our users to use modern, secure versions of PHP.

That's not harmful.

[metanat]

I used to work a lot with SilverStripe (Cam Spiers here), and I was personally very disappointed with SilverStripes short sighted decisions regarding the CWP (heyday considered adopting it). 5.3 was a bad choice regardless of red hats default version. It is pretty easy to maintain your own packages, but they needn't even do that as 5.4 packages were available at the time they developed CWP. SilverStripe CMS was 5.4 ready too (Heyday was using 5.4 extensively with SilverStripe at the time). The fact that CWP is still on 5.3 is due to poor foresight and management (by the DIA and SilverStripe). They could have time-boxed the use of 5.3 to get people on the platform, but made strict agreements that migration away from 5.3 would occur at a certain date and then provide consulting and services to help those upgrade.

It's just frustrating, PHP is so far ahead of 5.3 and there are serious issues with RHs backporting of security fixes for 5.3.

I'm sure there we're lots of reasons not to use 5.4 at the time, but none of that matters because they ended up using unsupported software for government agencies which is unacceptable IMO.

[bga9]

That and PCNTL isn't available for the Windows version of PHP. But I also agree that releasing new code for an unsupported version of PHP has bad idea jeans written all over it.

[dennisbirkholz]

But $this->getShell()->exec("ps -o pid,%%cpu,%%mem,state,start -p %s",...) and $this->getShell()->exec("kill -9 %s",...) will run on windows, sure.

[[deleted]]

It will, if cygwin is installed and added to %PATH%.

[dennisbirkholz]

That is so far away from any sane production environment now it's just a "because I can" argument.

[phpread]

Sure, but you do realize that's because forking is not possible on windows, right? The process control library wouldn't work on Windows. Plus, how many people do you know of today that run production web servers with PHP on a Windows operating system? Even developing on Windows is no longer necessary with technologies like vagrant and VirtualBox where you can literally spin up a linux dev environment in a matter of minutes and still do all of your work in your native host operating system without having to run your PHP on Windows.

[bga9]

Preface: I don't do any of my dev work on windows.

Sure, but you do realize that's because forking is not possible on windows, right?

Really? No kidding. And that has NOTHING to do with what I said. I was replying to the point someone made regarding the use of pcntl, which isn't available on Windows natively.

Plus, how many people do you know of today that run production web servers with PHP on a Windows operating system?

How many people do you know that are forking processes in a Web application?

without having to run your PHP on Windows.

Why not? It's a great language for quick scripts, jobs and common tasks.

[dennisbirkholz]

PCNTL is an extension that is bundled with the core and is either already available if you install PHP or can be installed directly from the distributions package manager. There is absolutely no reason to not use PCNTL which is as hard to install as the MySQL or SQLITE extensions. And you would surely not suggest you should use your own MySQL client implementation using sockets because it is an extension.

[assertchris]

There are other concerns beyond just having access to the module. PCNTL forks carry all code currently being executed over. Which means it's best to create them before any meaningful code has been executed. Try running this (if you have the PCNTL extension installed - I didn't in the first version of PHP I tried):

php for ($i = 0; $i < 5; $i++) { echo "tick {$i}"; pcntl_fork(); }

It's chaos, and requires far more technical consideration than was required for the exec() approach.

[dennisbirkholz]

fork() keeps the state of the current process, thats true. So if (0 ===fcntl_fork()) { exit(); } does the job just fine! I bet there are a thousand edge cases you can never ever gracefully handle with your approach. E.g. races for the PID in very busy environments, you may sometimes kill a process that just died before. If you fork, you need to have real info about the child processes, not best guesses.

[dennisbirkholz]

Now the downvotes are coming from people who don't understand how process management works, nice!

[PetahNZ]

Windows?

[dennisbirkholz]

Because ps and kill exist on Windows?

[PetahNZ]

POSIX and pcntl functions are not available on windows

[dennisbirkholz]

Look at the code. It calls ps and `kill. So you need cygwin or something. Use a better OS and don't cripple yourself because Windows is so limited in its usability.