On Tue, Mar 05, 2002 at 04:53:23PM -0500, Jeff Trawick wrote: > Here is the sequence of events: > > 1) a thread in child process A is waiting on semaphore > 2) graceful restart triggered > 3) parent process cleans up the semaphore > 4) that thread in child process A gets a failure (EIDRM) from the > semaphore obtain and gracefully brings down other threads in child > process A
My point is that #3 and #4 are in the wrong order. There should be nobody waiting on a semaphore when the parent cleans it up. > Normally in step 4 we'd get a high-severity log message. I changed > the code to set the severity to debug since everything is working as > designed. The process isn't going away prematurely, threads with > active connections have a chance to finish serving the connection, > etc. > > A variation on the sequence above is > > 1) a thread in child process B holds the semaphore and is blocked in > poll() > 2) graceful restart triggered > 3) parent process cleans up semaphore and wakes up children > 4) that thread in child process B returns from poll() and gets a > failure from the semaphore release and tries to gracefully bring > down other threads in child process B > > As with the previous scenario, everything is working fine. There is > no sense having a high-priority log message about an expected > condition. Again, same problem. The children should all be gone by the time the parent cleans up the semaphore. The POD should ensure that nobody is sitting in poll, since the single listener will wake up and read from the POD, signal all siblings to die, and then release the semaphore. -aaron
