httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: [PATCH] create fd slack (take 2)
Date Tue, 24 Jun 1997 08:47:34 GMT
Marc Slemko wrote:
> 
> On Mon, 23 Jun 1997, Randy Terbush wrote:
> 
> > > >From the fingers of Randy Terbush flowed the following:
> > > >
> > > >This raises the question, "Does this really belong in 1.2.1?"
> > > 
> > >     <HOBBY IMHO>
> > >     Yes, confound it.  1.2.1 is bug-fixes, if nothing else.  The
> > >     problem reports traceable to FD exhaustion are arguably the most
> > >     common ones we get.  If this patch either fixes it, increases the
> > >     threshold by a significant margin, or even just causes the server to
> > >     report errors rather than getting into a silent deadly embrace with
> > >     the OS, it's worth it.  Even if it does one of these things on only
> > >     a subset of the OSes we support, it's worth it.
> > >     </HOBBY>
> > > 
> > >     Out of curiousity, why *wouldn't* this belong in 1.2.1?  Is it a
> > >     feature?
> > > 
> > >     #ken    :-D}
> > 
> > Because of the portability issues with F_DUPFD as reported for the 
> > MPE and who knows what else. I raise the question since it would be 
> > pointless to release a 1.2.1 that suddenly doesn't compile or run 
> > on many supported platforms. Do we know?
> > 
> > File descriptor problems are nothing new. Releasing a 1.2 that 
> > suddenly doesn't work on many systems would not be considered a fix 
> > by those people encountering an F_DUPFD problem.
> 
> The point is, they _ARE_ new compared to 1.1.  I have to take off my shoes
> to count the number of people I have seen who had lots of virtual domains
> working fine with 1.1 that do not work with 1.2 period because of broken
> libraries.  Plopping a 1.2 binary in will break things where a 1.1 one
> worked.  People don't like being told they can't use 1.2 because their OS
> is broken when 1.1 worked fine.
> 
> That said, I am neutral on if it should be enabled by default or not...
> 

Now that I fully understand how the code works and the thought process
behind it, it seems like it's a good effort on Apache's part to take
care of an underlying OS problem. I'm guessing that most of the
platforms that Apache run's on, however, is not affected and that
most of the platforms that could be affected, aren't. And for those
affected, it should ideally be tunable...

Soooooo my opinion is that the fix would be best if a runtime,
httpd.conf option such that if 0 (or not defined) the behavior
is the exact same as NO_SLACK, but allowing for one to tune
the HIGH/LOW slack points by adjusting and HUPing.

Otherwise, disabled by default IMO, just to be safe.

-- 
====================================================================
      Jim Jagielski            |       jaguNET Access Services
     jim@jaguNET.com           |       http://www.jaguNET.com/
            "Look at me! I'm wearing a cardboard belt!"

Mime
View raw message