On Fri, Apr 27, 2001 at 06:12:56PM -0700, dean gaudet wrote:
> On Wed, 25 Apr 2001, Roy T. Fielding wrote:
>
> > replacement works better than what we have now in CVS. The claim
> > that the pipe of death is somehow better than 1.3 signals is just wrong.
>
> if you use signals then you have a requirment that all libraries linked
> with httpd be signal safe.
Sure, but that is a probability issue -- if the library is poorly written
then it is possible that a request will get hosed in mid-process during
a graceful restart. There is no real difference between that and the
fact that we don't read-lock every file while it is being sent. Services
that need stronger integrity (like big database back-ends storing transaction
records) will need to be signal-safe.
Anyway, what I meant was that until the pipe of death is proven to work
at least as reliably as signals, I don't think it is reasonable for anyone
to make blanket vetos on "regressing" the method to something which we
do know will work, albeit with the problem you mention.
The reason I have no confidence in the pipe of death as a solution is
simply that I haven't seen it work yet under stressful conditions, and
when I look at the code it just seems like something is wrong. Like,
why is it that workers_may_exit is never set to zero? Is it merely
because only the workers ever set it to 1, and once that happens it is
on the road to exiting the process in any case? Hmmm, maybe I'm just
forgetting that there is always a separate parent process that is
creating children, even on winnt and threaded.
And why does each worker grab a mutex before checking the pipe of death?
All that a worker does is check to see if there is a character on the
pipe and, if so, it tells all of the workers to exit. So why does it
matter if more than one worker gets inside that exclusion zone? *shrug*
....Roy
