Many years ago (I think it was in one of the Apache 1 versions), there was even an option to bring down the whole server at regular intervals and "reboot" it, just to clean up all accumulated junk and even now there is still a possibility to kill individual Apache worker processes after a certain number of uses.

The windows OS was particularly prone to it, but regularly doing "reboots" during quiet times seemed to avoid the worst effects. The only problem was trying to sell this "solution" to the head of IT as a "feature" rather than a kludge to deal with badly written software.

To clarify ...

Within my “persistent programs” of any sort, the outer level request handler contains an all-encompassing “exception handler of last resort,” and it carefully examines just what sort of exception has been thrown.

That is the reason why I use exception classes, which are objects.   (Yes, you can die with an object, as well as with a string.)   Code that cannot succeed throws an exception of a particular class.   (If it invokes code that might not use these classes, it “wraps” that code in an inner exception-handler which throws an exception-class containing among other things the text.)   Some exceptions are used as a way to gracefully bail-out from anywhere.   Others truly represent detected program flaws.   The outer-level handler will catch that fly-ball if nobody else does, and will do something appropriate.

It is true that any exception can leave various kinds of “smoking remains” which can accumulate; especially memory.   It happens often enough that Plack, for instance, has a so-called “hara kiri” facility which causes the workers to periodically die-off.   Sometimes the appropriate response to a certain exception is to die-off immediately.   But the outer level handler still has to capture the error traceback (another feature of these exception classes) and to sound the alarm somewhere.

Absolutely the worst thing that can happen is an exception that causes incomplete output and that is not correctly trapped or logged as an exception.   We have all seen web sites and so-forth that have done this.   Usually the output just stops in m

;-)

This behavior isn’t “strange” ... I think you hit the nail on the head as to its cause and the general remedy.   I have not yet personally used CGI::Fast, preferring instead to use Plack, but it does indeed appear to me that your FastCGI processes are crashing, after which they are necessarily being re-spawned.   A completely unhandled exception will cause any script to die, so this outcome must be prevented, because the causes of exceptions in production code cannot.   I think that the entirely-correct strategy is to wrap the body of that while loop inside of an exception-handling block, e.g. eval, so that any exception, no matter what the cause, will be explicitly trapped and some traceback given in a log.   (You may have to write code to do this.)   I am frankly puzzled why the examples for CGI::Fast do not include some kind of exception handling.   In general, the synopsis given seems simplistic, although I’m sure the code works well.

As I said, I customarily use include Plack, and, unrelated to that, part of the standard preamble for my modules is this:

use Try::Tiny;
use Exception::Class;
use Exception::Caught;
use except::classes; // a set of app-specific exception classes
use Error::Return;

You may wish to peruse some of these.   HTH...

Thank you for your input on this, valuable indeed! I will do some testning, and will maybe also have a look at Plack. Thanks!

Somewhat of a tangent to your original question but please check out Plack. It will make your life much much easier in the short and long run.