httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Murcko <ch...@telebase.com>
Subject Re: update ii
Date Sat, 17 Jun 1995 15:39:15 GMT
Rob Hartill liltingly intones:
> 
> 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."
> 
> 
> 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.
> 
> 
This looks like SOP in other code I've seen, and not too terribly ugly except
to purists, which I'm not. I'm excited because you may just have triggered
the thoughts which lead to the Solaris fix. Unfortuantely, There are real
problems with 0.7.2j eating up all the file descriptors under FreeBSD and
BSDI under heavy load, and I have to look at those first. Good work on the
trimming of the server. Take it lightly.

chuck
Chuck Murcko	Telebase Systems, Inc.	Wayne PA	chuck@telebase.com
And now, on a lighter note:
186,282 miles per second:

It isn't just a good idea, it's the law!

Mime
View raw message