httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brandon Long <bl...@uiuc.edu>
Subject Re: update ii
Date Sat, 17 Jun 1995 05:48:07 GMT
Last time, Rob Hartill uttered the following other thing:
> 
> 
> well the suckers are down to 260k each at startup (was 548k), so that's
> promising.. trouble is that a SIGHUP (restart) causes the new children
> to die when servicing any request :-(
> 
> 
> So, how ugly is the following suggestion...
> 
> Rather than have the parent process attempt to cleanup after
> a SIGHUP, it could do the following..
> 
> very early in the code (first line maybe),
> 
>    while((pid=fork()))             /* while it was you that called fork */ 
>       waitpid(pid, NULL, 0);       /* wait for the child to exit */
>                                    /* child falls through */
> 
> 
> Then a SIGHUP can be handled by writing "bye bye" to the error log, 
> followed by an exit(0);
> 
> It's a lot easier than using siglongjump and freeing loads of resources.
> 
> I just looked at the man page for siglongjmp; it's storing a pile of
> info much like a 2nd process would anyway, but the man page also says
> 
>     "But, because the register storage  class  is  only  
>      a  hint  to  the  C  compiler,
>      variables declared as register variables may not necessarily
>      be assigned  to  machine  registers,  so  their  values  are
>      unpredictable after a longjmp().  This is especially a prob-
>      lem for programmers trying to  write  machine-independent  C
>      routines."

This is actually a problem with 1.4.1 if you use gcc -O2 on Solaris
and SunOS.  It causes a SIGBUS after the set jump in the main process
after a SIGHUP.

> so my alternative might not be so bad after all.
> 
> It might also be worth ditching the children's longjump handling and
> just let them exit whenever they would otherwise jump. N.B. they'll be
> replaced with a new child almost immediately.

We haven't noticed as much of a problem with the children.  The problem
is how often die() is called.  If more of the die()'s could be handled
instead of actually die'ing, then it would probably be worth it.  B18
helped, for instance.  You're not going to get around the sigalrm 
and sigpipe, but the If-Modified-Since probably happens a little too
often (causing a die(USE_LOCAL_COPY)).  

hmmm

Brandon
-- 
 Brandon Long   (N9WUC)     "I think, therefore, I am confused." -- RAW
 Computer Engineering   	Run Linux '95.	It's that Easy. 
 University of Illinois    blong@uiuc.edu   http://www.uiuc.edu/ph/www/blong
		Don't worry, these aren't even my views.

Mime
View raw message