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.

In this new post, titled "PHP is meant to die", the author looks at one weakness he sees in the PHP language - how PHP handles long running scripts and functionality.

In my opinion, a lot of the hatred that PHP receives misses the utter basic point: PHP is meant to die. It doesn’t mean that a perfectly capable (to some extent) programming language will disappear into nothingness, it just means that your PHP code can’t run forever. Now, 13 years after the first official release in 2000, that concept still looks valid to me.

He talks about some of the "dying" that PHP is good at (like making general website-related requests) but notes that if you try to have it do much more, PHP acts up. He points to the complexity of web-based applications and notes that, while PHP is good for some of it, it's not a fit for all functionality. He also covers the bringing of processes to the foreground that are best left in the background and how - despite the best of intentions - making a PHP daemon to solve the problem isn't a viable option.

Do you see the pattern? I’ve inherited projects where PHP was used for daemons or other stuff that’s not just regular websites (yes, I’m a hired keyboard), and all of them shared that same problem. No matter how good or clever your idea looked on paper, if you want to keep the processes running forever they will crash, and will do it really fast under load, because of known or unknown reasons. That’s nothing you can really control, it’s because PHP is meant to die. The basic implementation, the core feature of the language, is to be suicidal, no matter what.