mod_perl and exit

[Rob Hartill <ro...@imdb.com>]

People have also found a need to let mod_perl 'scripts' call
exit in order to recover huge amounts of memory.

It's very easy to write Perl code under mod_perl to deliberately
consume lots of memory to get a job done quickly. There's no effective
way to recover memory used by Perl other than to nuke the process.
If you're lucky you can wait for the process to serve all its allocated
requests then die a natural death, but if you're short on memory then
its a blessing to have a way to self destruct the process.

You might not like that way of programming but it comes in very handy
for big mod_perl projects.

Another use for exit in mod_perl (dunno if it's still necessary) was
as a way to jump out of deep layers of subroutine calls. Calling
GOTO out of a subroutine just confuses the hell out of "mod_perl"
(I think the problem was to do with the stack pointer being way off
after the jump). The code can be rewritten to allow
graceful "return"s from these subroutine calls but sometimes
it's not your code or it's part of some module you just can't
touch or ...

I had to rewrite my code to return from dead-ends deep in a chain
of subroutines, but until I finished that, 'exit' was the solution. At
least one other mod_perl user reported getting into the same situation.
If you have big CGI scripts, chances are you'll hit this problem porting
them to mod_perl.


--
Rob Hartill                              Internet Movie Database (Ltd)
http://www.moviedatabase.com/   .. a site for sore eyes.

Re: mod_perl and exit

[Alexei Kosut <ak...@organic.com>]

On Thu, 31 Jul 1997, Rob Hartill wrote:

> People have also found a need to let mod_perl 'scripts' call
> exit in order to recover huge amounts of memory.
> 
> It's very easy to write Perl code under mod_perl to deliberately
> consume lots of memory to get a job done quickly. There's no effective
> way to recover memory used by Perl other than to nuke the process.
> If you're lucky you can wait for the process to serve all its allocated
> requests then die a natural death, but if you're short on memory then
> its a blessing to have a way to self destruct the process.
> 
> You might not like that way of programming but it comes in very handy
> for big mod_perl projects.

I'm not sure what your defenition of "handy" is, but I know mine doesn't
include short-circuting Apache's request mechanism and completely
destroying the request model Apache uses. If mod_perl actually lets you
exit the process in the middle of a handler, I believe it should be taken
out and shot.

There are things Apache does, besides log_transaction, after processing a
handler, that really are not at all appropriate to do without, unless
you're talking about something really bad like a core dump. Examples: If
you are using chunking, exit-ing in the middle of the handler will not
turn chunking off (send the terminating chunk), which will screw up
HTTP/1.1 clients. If you're using exit() at the actual termination of a
Perl script (i.e. you've send headers, body, etc...), then this just
won't work at all. Also, the new child_exit phase. If Perl exits, then
this never gets called - the whole point of child_exit is that things can
happen when the process ends.

If it is neccessary for mod_perl to mark the request as the last one the
process can handle, because the Perl interpreter is screwed up, or is
using too much memory, I don't have a problem with that. I do have a
problem with it just randomly exiting.

Surely there are ways around this. Doug, you said you had overrided
exit() to call log_transaction() and then a C exit() - couldn't you
instead goto back to the request handler, which could return normally?
It's ugly, but it could work...

-- Alexei Kosut <ak...@organic.com>