> > > > FWIW, my JRE_1 tag does *not* have this change. rbb and I agreed > > > > that it wasn't necessary to have the signal-less worker MPM in any > > > > beta as it doesn't affect modules. It also gives time to stablize > > > > problems like these. > > > > > > yep... roll on... > > > > > > unclear what problem was actually being fixed by getting rid of > > > signals anyway (though that is a misnomer; you don't get rid of > > > signals on Unix) > > > > There were two problems > > > > 1) Signals suck in threaded apps on Unix, and they also suck in > > daemons. We had a lot of magic in the code to make sure that the signal > > got to the correct thread and that it was able to do something with it. > > Today, we got rid of the magic, because we don't use signals to > > communicate between parent and child. > > There are always signals, whether or not the parent uses a signal to > wake up a child. We still need to make sure that asynchronous signals > go to a particular non-worker thread.
There are no threads in the child process sitting in sigwait. The child only responds to the parent process, and then only through the POD. Since there are no threads in the parent, there is no need to direct signals to a particular thread. > What is the magic you're talking about? > pthread_sigmask()/sigprocmask()? That seems to be required anyway. In the child process, all we do now is ignore all signals. Previously, we blocked signals in all threads, then we created a signal handling thread that sat in sigwait. All of that is gone now. > > 2) We used to do a non-blocking read at the start of every request on a > > pipe that was usually empty. That was a waste of a syscall. By > > removing the signal thread, I was able to move the POD checking to a > > single location, and now we have one thread that just listens for > > information from the parent and decides what to do with it. > > I suspect that what you really mean is that the thread which gets > signals no longer blocks in sigwait() but now blocks on the POD and > lets the signal handler be driven asychronously, waking up the > blocking POD call. Or is there now no way to shut down when a signal > arrives? There is no way to shutdown when a signal arrives. ALL communication is done using messages over POD, shutdown and restart are BOTH done over the POD. The only signal that can shutdown a child process is a SIGKILL, and that is only used if the process doesn't die because of the message over the POD, which is a bug. Ryan
