"Ryan Bloom" <[EMAIL PROTECTED]> writes:
> > > 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.
What is the magic you're talking about?
pthread_sigmask()/sigprocmask()? That seems to be required anyway.
> 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?
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
