In his previous post ("PHP was meant to die") the point was made that PHP isn't really designed as a language to handle long running processes very well. It's made to handle a few operations and then die at the end of the request. In this follow up post he talks more about using PHP for long running processes and a library that could help.

Yes, I already acknowledged that PHP has a garbage collection implementation starting 5.3.0 and up (opt-in or opt-out, that's not the problem). I also acknowledge that garbage collection works, and is able to take care of most circular references just fine. [...] Anyway, as previously stated too, garbage collection is a great thing, but not enough for PHP. It's a borrowed feature that does not play well with old fundamental decisions inherited from the original design. Garbage collection is not a magical solution for every problem, like many tried to argue about. Let's illustrate with another example.

His example uses the React PHP library (a non-blocking I/O platform) to handle a lot of incoming data to a port and report back some memory usage and limit settings. He explains a bit about what's happening and shares the results of the test, including the end result - a fatal error when the memory limit was hit. He still comes to the same conclusion, ultimately...PHP is just not the language to use for long-running processes that do any large amount of work.

Gonzalo Ayuso has a new post today showing how he set up queuing with ZeroMQ and Symfony components and React.

Today I'd like to play with ZeroMQ. ZeroMQ is a great tool to work with sockets. I will show you the problem that I want to solve: One web application needs to execute background processes but I need to execute those processes in order. Two users cannot execute one process at the same time. OK, if we face to this problem we can use Gearman. I've written various posts about Gearman (here and here for example). But today I want to play with ZeroMQ.

He uses React and some ZeroMQ bindings and Symfony's Process component to make a simple client and server for working with the queue and processes. A screencast is included in the post showing them making the connection and adding the new process. The full code can be found on github (or installable via Composer)

On PHPMaster.com there's a new tutorial that introduces you to React, the PHP-based event-driven non-blocking socket tool that's similar to some of the functionality Node.js provides. The article is a very basic introduction but can help get your feet wet with the tool.

For the past couple of years, Node.js has been drawing increasing amounts of attention as a promising web technology. While it has some strengths, like being event driven, some people just want to stick to PHP. For over a year now, however, there has been a similar project for PHP named React. React is mostly coded by Igor Wiedler, who is also a prominent contributor to the Silex framework. While reading through the React examples, it really does look similar to Node.js.

Included in the post are the instructions on how to get the latest version of React (via Composer) and the code to create a sample server that just writes out a string with a counter for the number of requests made. There's also an example of a "keystroke logger" for all data that's coming across the connection. The author (Igor) notes, however, that he wouldn't recommend using React in production, though, as its target is mostly those working with "cutting-edge technologies" rather than more stable applications.

In this latest post Gonzalo Ayuso his recent experiences with <1 href="http://nodephp.org/">React (Node.js in PHP) and an example of how he worked up a script to pool database connections.

Last saturday I meet a new hype: "React" also known as "node.php". Basically it's the same idea than node.js but built with PHP instead of javascript. [...] Basically I want to create a database connection pooling. It's one of the things that I miss in PHP. I wrote a post here some time ago with this idea with one exotic experiment building one connection pooling using gearman. Today the idea is the same but now with React.

He includes the sample script, also including the line to add to your composer.json file to install React and the SQL to create the sample tables. The script makes a PDO connection and assigns it to the pool, an instance of his "CPool" class. If you want to try it out, you can find the code over on github.

There's always been several PHP developers out there looking to protect the source that they so lovingly crafted. They look for alternatives to keeping it safe, but sometimes it's just not enough. In this new post on the Sjon.Blog today, he mentions some of the frustrations he's had already with exectly this.

Zend almost convinced me that their Safeguard Suite really secured your PHP scripts. Ofcourse I know that scripts need to be interpreted and executed and are therefore never 100% safe; but I expected some form of obfuscation and rewriting to prevent this. This doesn't seem to be the case though. I have had a look at PHP Obfuscator/Obscurer, but a good illustration of the quality of that script can be illustrated with a simple, readable example.

Also, obfuscating React took me almost an hour; which isn't that strange when you have had a look at the sourcecode.

As far as I've heard/seen so far, there's not really a good solution to this dilema. Sure, some are better than others, but there's still a hole there that is just waiting to be filled with an application anyone can use...