PHP is meant to die

Death by design doesn't work for everything (which is why I hope your database server and your filesystem aren't written in PHP), but it's a great fit for handling HTTP requests that are shunting data around.

You can, and probably should, use other languages to process data in batches, and whatever maintenance needs to be done. It would be nice sometimes to be able to finish a client request, and then continue to do more work, you can approximate that by forking a background task (hopefully with some sort of limit to avoid crushing your machine), or a call to a task daemon.

Knowing that the PHP process lifecycle is very short helps you prioritize things too. Do you really want to spend time making a giant object oriented representation of your relational database, when you're just going to throw it away in 50 ms; wouldn't you rather spend more time with your kids?

I agree, PHP employs very suicidal workers!

Chromium workers die after you've closed their respective tabs. Once the page finishes loading the worker is no longer needed, another one can pick up the next request. I've never come across the line 0 error, I don't task a single PHP script with a respectably large operation, it's not designed for that - even the default script execution timeout offers a hint.

Obviously session information and state can be stored in a cache, database or file. If you need to trigger a maintenance script create an XHR or cron job. 1x1 transparent PNGs is a horrible way to do some back-end dirty work that the client need not be associated with. If you're doing this to run DB optimization, purges or bulk emailers, you're doing it wrong.

An obscure limitation? Yes, but there are bigger issues in PHP than death-by-design.

... The reddit thread about this had more insight than hackernews.

I don't get why the author want to freaking do long daemon in PHP. Even if so, there are people on reddit that talked about coding long process in PHP with failure in mind (that's like something you learn from Erlang and fault tolerant system). He/she could use a message queue if need it be.

And really? You want state in your web application? with HTTP protocol that is stateless?

It's almost like picking on a donkey cause it ain't a bird.

And he/she doesn't even offer a concrete solution. If PHP suck so bad, by all mean post a solution or an alternative.

And I am going to disagree with meant to die. PHP is actually evolving into a pretty language even if it's fundamentals are flawed.

I don't think PHP is going to die, it have adopted namespace, anonymous function, closure, and soon generator and whatever. Not only that but it recently got an awesome package management system, composer. It's going to stay for a long time. It's evolving and moving in a good direction with an existing user base.

First, let me say that I do agree with this post. PHP projects are more often than not full of inelegant solutions written by bad programmers. The "running background tasks in the foreground" is a good example; one that I _hate_ seeing in production.

The thing that I don't agree with though, is that you've described a "capable" programmer who uses good programming techniques and obviously knows how to structure an application. If this programmer is doing the "background-in-foreground" thing and hasn't heard of message queues, then I would argue that they aren't a capable programmer - in which case you're just describing bad programming practices; not a fundamental flaw of PHP.

From my experience working with PHP for over 13 years (since PHP 3 was new), I can say your article is mostly true, and I have definitely seen the invisible-image-as-a-poor-mans-cron trick in production a time or two. The only nitpick is that I have really only seen stuff like this on small sites that don't have enough traffic for it to ever matter, so it's generally a temporary issue or a stop-gap measure, not common practice as was implied.

That said, there's nothing stopping people from just throwing a task in Redis from their PHP frontend and using node.js or Python, or Ruby to manage the queue. This is what Flickr did (http://code.flickr.net/2012/12/12/highly-available-real-time...), and it seems to work well for them. People just have to keep in mind what each language excels at and know the drawbacks. Articles like yours help, so thanks for the good read.

I liked the post but you can definitely use that factor to your advantage. Its all really subjecetive, if you have code that is structured to die and not be continuously running then you probably wouldn't run into any problems, that said, PHP is arse.