I was under the impression that when the user hit stop, the script stopped. Which is: bad, and wrong. PHP doesn't detect that the user has terminated the connection, it has no clue, it obligingly continues processing along, until it attempts to send information to the user. Now, just because you have an echo statement, doesn't mean that information is necessarily being sent to the user, buffering (not necessarily output buffering, PHP and your web server also implement some buffering) will probably catch it. It's not until that buffer is filled, or you call something like flush() that information is actually sent, and thus PHP would know the user has aborted.
When might you want to ignore a user abort? Well, simply put, any situation where you're executing a series of sequential actions and stopping in the middle would leave your application in a bad state (transactions are the database solution for this, they're simply rolled back if you disconnect without committing (unless you're using a persistent connection)).
In short, the user aborts when they close their browser, hit stop, etc. PHP however doesn't know the user has aborted until it actually attempts to send them data.
Comments »
If you’re looking for a way to keep a PHP script running on the server even after the user navigates from the page or hits the stop button, you can use the “ignore_user_abort” flag in the php.ini file or set it using ini_set function...
Tracked: Oct 03, 14:26
PHP automatically closes any open files when it shuts down (also releasing any locks you might have placed) so you don't have to worry about things left hanging.
That being said, there is one possible concern, if you're writing data to a file, and echoing out data in the middle, you could end up with a file that only has a subset of the amount of data you want it to contain.

Tracked: Oct 03, 12:26