httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: clean_child_exit, just_die and exit
Date Fri, 28 Sep 2001 01:50:11 GMT
dean gaudet <dean@arctic.org> writes:

> On 26 Sep 2001, Jeff Trawick wrote:
> 
> > @@ -2785,7 +2791,11 @@
> >  static void usr1_handler(int sig)
> >  {
> >      if (usr1_just_die) {
> > -	just_die(sig);
> > +        if (alarms_blocked) {
> > +            exit_after_unblock = 1;
> > +            return;
> > +        }
> > +        ap_longjmp(die_jmpbuffer, sig);
> >      }
> >      deferred_die = 1;
> >  }
> 
> longjmp() isn't safe either...
> 
> basically there's nothing in C that you can do safely in a signal handler
> except set a global variable.

I agree in principle, but reacting to the global variable in a
reasonable period of time (e.g., before grabbing another connection in
the case of graceful restart) may be impossible without changing our
expectations a bit.  Other than allowing the possibility that we serve
yet another request after SIGUSR1 is received, I don't see how to
handle the problem.

> longjmp() isn't safe for the same reasons atexit() and cleanups aren't
> safe in the presence of arbitrary 3rd party code:  the 3rd party code
> could be in a state that would require rollback or cleanup before it's
> safe to re-enter that 3rd party code.

There is a decent chance that the 3rd party code won't be re-entered
anyway due to our desire to exit the process as a part of handling the
signal.  This is just lowering the risk slightly :(

> when i last played with the 1.3 signal handlers i just chose performance
> over correctness in this case, i got tired of having to pay so many
> signal() syscalls to make the thing safe.  i was hoping signals would just
> go away in 2.0... but i've never helped make that happen.

The second best time to plant an oak tree is ... :)

> when it comes right down to it, you have to say fuck it at some point.
> either you die gracelessly, or the admin shoots you with a kill -9 at some
> point.  if graceless death is going to happen you might as well make it
> happen early rather than later.  (you've seen me argue recently that
> there's no sense trying to recover from out of memory errors, this is all
> part of that same argument.)

We can longjmp out of the signal handler and have to say "fuck it" in
a smaller set of situations.

I'm not sure it is possible to take the pure set-a-global approach
without revisiting the requirements for how certain signals are
received.

for sigusr1: 

  we could handle yet another connection

for sighup/sigterm:

  we could sprinkle the code with checks for the global variable to
  react fairly quickly or we could end up finishing the current
  request (if we don't get SIGKILLed by the parent first).

I dunno :(
-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Mime
View raw message