httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug MacEachern <>
Subject Re: mod_perl and exit
Date Thu, 31 Jul 1997 13:00:47 GMT
Alexei Kosut <> wrote:

> 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.

I feel the same way.  But, exit() is a CGIism that some people expect
to work under mod_perl, I've only made a minimal effort to emulate
it's behaviour.  I tend to say "don't do that", advising to get
rid of any exit() calls, in almost every case that is possible.

> 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.

Right, but when mod_perl's exit was introduced, there was not chunking
and no child_exit().  But, I was always uncomfortable that using it
would by-pass an important part of the request.  
> 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...

The problem is, the exit() subroutine is called while Perl is in the
middle of walking an op tree.  The only way to stop it is by cutting
off it's legs with C-level exit or Perl's croak().  Neither is quite
good enough.  I'll have to go back to the drawing board for this,
either in mod_perl or Perl itself.

> -- Alexei Kosut <>

View raw message