It sucks to have to use gettimeofday() to find out how long select() took. I wonder if reclaim_child_processes is really necessary now that we've eliminated many of the race conditions involving signals.
Oh yeah this definately happens, I've done a "while 1; kill -HUP" loop and I see the errors in the log occasionally. But I haven't been worried about it yet. masking is probably the best solution. Dean On Thu, 26 Jun 1997, Nathan Kurz wrote: > > >Number: 795 > >Category: general > >Synopsis: a flood of signals can confuse reclaim_child_processes() > >Confidential: no > >Severity: non-critical > >Priority: medium > >Responsible: apache (Apache HTTP Project) > >State: open > >Class: sw-bug > >Submitter-Id: apache > >Arrival-Date: Thu Jun 26 15:20:00 1997 > >Originator: [EMAIL PROTECTED] > >Organization: > apache > >Release: 1.2.0 > >Environment: > any > >Description: > The select calls in reclaim_child_processes() can be cut short by signal > interruptions. If enough signals are coming, none of the wait times > will happen and the lot's of unnecessary errors will be logged. > The child processes should still die just the same, though. > >How-To-Repeat: > I'm not sure if you can. It might only be a theoretical problem ;) > I found it by in a piece of code I wrote that was very similar to this > routine and haven't actually tested it in Apache. > >Fix: > I had success masking off certain signals around the select() statement. > In particular, I call sigprocmask to mask and unmask SIGHUP and SIGTERM > before and after the select(). Apache might want to do these and > SIGUSR1 > >Audit-Trail: > >Unformatted: > > >
