Any FastCGI server is a persistent process, usually but not necessarily spawned by Apache, which sits on one end of an inter-process communication (IPC) channel with Apache at the other end. When Apache gets a request and decides that it’s for FastCGI, it sends a message down the channel. One of the servers picks it up, generates the reply, and sends it back to Apache. Then, the server goes back to sleep again. Meanwhile, Apache grabs the response and sends it back to the client.
I happen to prefer to do things this way, vs. mod_perl, because it keeps the Apache request-handlers small and also because it lets me deploy the FastCGI servers behind an internal firewall, where they are being fed by Apache/nginix servers that themselves don’t have access to anything. (There’s just a soda-straw sized opening between the two, and only FastCGI data can get through.) A really big operation might have several different servers handling different URLs. I often use the Plack module for this interface, vs. the one you are using here, but that’s just me or my habit. (And I don’t want to divert this thread into a philosophical debate on these points.)
Clearly, this package sleeps in the constructor, hands back an object containing the request, and captures whatever you print as the response that is to be returned, taking care of the delivery and plumbing behind-the-scenes like a good package should.
Now, specifically addressing your question about exit: Every now and again, a FastCGI server will choose to “commit hari-kiri,” voluntarily terminating itself (e.g. to curtail the effect of memory leaks). Apache will re-spawn its replacement. That’s what you see in the $exit_flag bit ... which is clearly just a for-instance. For instance, you might arbitrarily decide that a module should service, say, 1,000 requests and then terminate so that the OS can clean-up its memory. So you’d initialize and increment a counter, then exit when it reached or exceeded 1,000. I presume that this module catches the attempt so that it can send the response data back to Apache and close the connection before the process actually dies. Also, IIRC, you can call for hari-kiri behavior in the Apache configuration settings, asking Apache to keep a count and to kill its darlings. One way or the other, Apache (or a FastCGI monitoring daemon of some kind) sees the body, cleans it up, then grabs another “instant FastCGI service process, just add water!” package and adds water to it. :-) A replacement instance of the FastCGI process is now off-and-running, and life goes on blissfully as it should.
Do be mindful that there is more-than-one Apache module available for FastCGI support, and that the two are not quite the same. This package, IIRC, is using the “newer” one of the two, as it should. I think that the original, mod_fastcgi, is now considered deprecated.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
Outside of code tags, you may need to use entities for some characters:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||